From isis-wg-admin@ietf.org  Thu Aug  1 03:25:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04320
	for <isis-archive@odin.ietf.org>; Thu, 1 Aug 2002 03:25:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17210;
	Thu, 1 Aug 2002 03:24:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17180
	for <isis-wg@optimus.ietf.org>; Thu, 1 Aug 2002 03:24:37 -0400 (EDT)
Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03852
	for <isis-wg@ietf.org>; Thu, 1 Aug 2002 03:23:29 -0400 (EDT)
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <P9P43WJX>; Thu, 1 Aug 2002 03:07:47 -0400
Message-ID: <E7E13AAF2F3ED41197C100508BD6A3286665F8@india_exch.hyderabad.mindspeed.com>
From: "Jonnala, Nagi" <nagij@netplane.com>
To: "'Jeff Parker'" <jparker@axiowave.com>
Cc: isis-wg@ietf.org
Date: Thu, 1 Aug 2002 03:10:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Isis-wg] isisCircTable of ISIS MIB --- IP address
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Jeff,

isisCircTable currently doesn't have any distinguished entity
apart from circuitIndex, a integer value.

Hence, it might be difficult to Network Admin. guy to comprehend 
a isisCircEntry. I believe He might be able to understand well 
if we can give some sort of more meaningful than a mere index number.

Don't you think it would be nice if we can have "IP address" 
field which could be "read-only" access?

Thanks
Nagi.


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug  1 05:01:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10698
	for <isis-archive@odin.ietf.org>; Thu, 1 Aug 2002 05:01:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22517;
	Thu, 1 Aug 2002 05:01:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22473
	for <isis-wg@optimus.ietf.org>; Thu, 1 Aug 2002 05:01:05 -0400 (EDT)
Received: from cisco.com (mrwint.cisco.com [144.254.98.48])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10578
	for <isis-wg@ietf.org>; Thu, 1 Aug 2002 04:59:55 -0400 (EDT)
Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp13.cisco.com [144.254.108.80])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA13507;
	Thu, 1 Aug 2002 10:00:02 +0100 (BST)
Message-Id: <4.3.2.7.2.20020801095057.02dc9dd8@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 01 Aug 2002 10:00:00 +0100
To: "Manral, Vishwas" <VishwasM@netplane.com>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology
Cc: isis-wg@ietf.org
In-Reply-To: <3D481CFF.10402@net4u.ch>
References: <E7E13AAF2F3ED41197C100508BD6A3282920F5@india_exch.hyderabad.mindspeed.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Manral,

This is VERY important. The specification MUST be restricted to what can be 
observed on the wire. i.e. the packet formats and the operation of the FSM. 
Anything which doesn't affect that has no place in the specification.

In the context of the current discussion about MT, of course the way you 
forward certain data packets as a result of the routing protocol 
information you receive *is* an externally visible phenomenon, and 
therefore the spec has a right (and a duty) to dictate it, but it doesn't 
have a right to dictate the internal mechanisms which you use to achieve 
that required behaviour.

In other words I STRONGLY agree with Tony.

         Mike

At 10:23 31/07/2002 -0700, Tony Przygienda wrote:
>Manral, Vishwas wrote:
>
>>Hi Tony,
>>
>>My doubt does not relate to the MT draft, however I have had this doubt for
>>some time now and thought this may a right time to clarify(in context of the
>>discussion).
>>
>>Don't you think items that can be done internally, without affecting
>>interoperability but can be useful for the ISIS community as a whole be also
>>pursued by the ISIS-WG?
>nope, some attempt at this kind of stuff have proven failures in the past 
>... Just imagine what
>will happen if you unknowningly suggest a 'MUST' for an implementation 
>technique that some major
>competitor of yours cannot incorporate into his deployed, successfull 
>implementation. Ultimately,
>do you think he'll even care to follow such a 'MUST' ?  And how would 
>exactly prove that he
>does not follow this 'MUST' ?
>
>There is a small grey area but it is normally better to not get into 
>'internal operations or
>implementation techniques' unless there is no other choice.
>
>>
>>It seems to me "document current protocol implementation practices and
>>improvements" is a chartered goal of the working group.
>that always means 'as far as they can affect inteoperability'
>
>    -- tony
>
>
>
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Fri Aug  2 17:00:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06176
	for <isis-archive@odin.ietf.org>; Fri, 2 Aug 2002 17:00:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08035;
	Fri, 2 Aug 2002 17:00:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08004
	for <isis-wg@optimus.ietf.org>; Fri, 2 Aug 2002 17:00:35 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06120
	for <isis-wg@ietf.org>; Fri, 2 Aug 2002 16:59:25 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57BA8@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Jonnala, Nagi'" <nagij@netplane.com>
Cc: isis-wg@ietf.org
Date: Fri, 2 Aug 2002 16:59:25 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Isis-wg] RE: isisCircTable of ISIS MIB --- IP address
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

> Jeff,
> 
> isisCircTable currently doesn't have any distinguished entity
> apart from circuitIndex, a integer value.
> 
> Hence, it might be difficult to Network Admin. guy to comprehend 
> a isisCircEntry. I believe He might be able to understand well 
> if we can give some sort of more meaningful than a mere index number.
> 
> Don't you think it would be nice if we can have "IP address" 
> field which could be "read-only" access?
> 
> Thanks
> Nagi.

Nagi -
	I'm prepared to be educated on this one.

	My problem with duplication of information is that when
you store something twice, you introduce the problem of data
consistency.  Assume the interface has multiple IP addresses.
Which do I report?  

	I have a hard time imagining a Network Admin guy that 
doesn't understand ifIndex, or a CLI/MIB viewer/Web browser
that isn't smart enough to link ISIS circuits to the underlying
information in MIB II.  

- jeff parker

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 16:59:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12490
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 16:59:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07803;
	Sun, 4 Aug 2002 16:59:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07777
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 16:59:00 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12453
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 16:57:46 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g74L0N924156
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 23:00:23 +0200
Message-ID: <3D4D9138.1040002@net4u.ch>
Date: Sun, 04 Aug 2002 13:40:24 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: isis-wg@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Isis-wg] admin tags and p2p over ether not on the isis WG page ...
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Admin Tags seems to have expired or was it never submitted as ISIS draft?
 Could the authors repost it pls. I thought the rough consensus was to 
take it on ? 

and where is

draft-ietf-isis-igp-p2p-over-lan-00.txt  ?? Unless the authors gave up on it ?


    thanks

    --tony



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 19:36:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15385
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 19:36:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15720;
	Sun, 4 Aug 2002 19:33:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15690
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 19:33:00 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15294
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 19:31:47 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 54B004BA216; Sun,  4 Aug 2002 16:32:58 -0700 (PDT)
To: prz@net4u.ch
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] admin tags and p2p over ether not on the isis WG page ...
In-reply-to: Mail from Tony Przygienda <prz@net4u.ch> 
 dated Sun, 04 Aug 2002 13:40:24 PDT
 <3D4D9138.1040002@net4u.ch> 
Date: Sun, 04 Aug 2002 16:32:58 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020804233258.54B004BA216@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

 ] 
 ] draft-ietf-isis-igp-p2p-over-lan-00.txt?? Unless the authors gave up on it?
 ]

i think we gave up on updating a new version due to there is no change to
the old version(except for some contact info change). we can submit a new
one if that's the way to keep the draft until LC.

thanks.
- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 19:46:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15571
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 19:46:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16094;
	Sun, 4 Aug 2002 19:43:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16066
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 19:43:09 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15470
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 19:41:56 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g74NiU917419;
	Mon, 5 Aug 2002 01:44:30 +0200
Message-ID: <3D4DB7AF.2020209@net4u.ch>
Date: Sun, 04 Aug 2002 16:24:31 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Naiming Shen <naiming@redback.com>
CC: isis-wg@ietf.org
Subject: Re: [Isis-wg] admin tags and p2p over ether not on the isis WG page
 ...
References: <20020804233258.54B004BA216@prattle.redback.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Naiming Shen wrote:

> ] 
> ] draft-ietf-isis-igp-p2p-over-lan-00.txt?? Unless the authors gave up on it?
> ]
>
>i think we gave up on updating a new version due to there is no change to
>the old version(except for some contact info change). we can submit a new
>one if that's the way to keep the draft until LC.
>
yes, please, unfortunately that's the only way to keep things around, 
otherwise they expire ... I don't
think I saw any discussion on the list for a long time so we may think 
about last-calling it pretty soon ??

    thanks

    -- tony




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 19:50:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15724
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 19:50:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16387;
	Sun, 4 Aug 2002 19:47:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16357
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 19:47:15 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15556
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 19:46:02 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 21CF14BA216; Sun,  4 Aug 2002 16:47:07 -0700 (PDT)
To: Alex Zinin <zinin@psg.com>
Cc: Tony Przygienda <prz@net4u.ch>, Naiming Shen <naiming@redback.com>,
        stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology 
In-reply-to: Mail from Alex Zinin <zinin@psg.com> 
 dated Tue, 30 Jul 2002 14:19:51 PDT
 <1354453984.20020730141951@psg.com> 
Date: Sun, 04 Aug 2002 16:47:07 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020804234707.21CF14BA216@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


We'll put out another version of the MT draft soon. thanks.

 ] Folks-
 ] 
 ]  Before I leave the exact wording decisions in the capable hands of
 ]  this WG, I'd like to give my perspective on the issue of the scope of
 ]  this document.
 ] 
 ]  What we have here is not just yet another useful ISIS TLV. We're
 ]  talking about different forwarding behavior and routing calculations
 ]  supporting it. As such, we need to give enough clue to the reader
 ]  about the forwarding process and RIB/FIB construction to make sure we
 ]  do not end up receiving mid-night support calls and troubleshooting a
 ]  permanent routing loop because someone misinterpreted the spec. The
 ]  smart-guys-will- figure-out argument is just not good enough. I do
 ]  not see a problem in giving some generic rules that need to be
 ]  followed and giving some valid examples of the approaches that can be
 ]  used to implement them (as opposed to limiting implementations to
 ]  them only). I guess my point is that routing is too important, so I'd
 ]  rather us err on the side of descriptiveness. It might be a good idea
 ]  to consider adding a separate section that talks about forwarding
 ]  implications...
 ] 
 ]  Thanks.
 ]  
 ] -- 
 ] Alex
 ] 
 ] Tuesday, July 30, 2002, 11:02:40 AM, Tony Przygienda wrote:
 ] > Naiming Shen wrote:
 ] 
 ] >>Stefano,
 ] >>
 ] >> ] On Tuesday 23 July 2002 23:51, Alex Zinin wrote:
 ] >> ] > Tuesday, July 23, 2002, 9:00:14 AM, Tony Przygienda wrote:
 ] >> ] > > Stefano, here's my opinion modulo Naiming's one
 ] >> ] >=20
 ] >> ] > > In a sense, what you say is correct, if you read the 'MUST' as an=2
0
 ] >> ] > > implementation guideline. The intention
 ] >> ] > > was to say 'provides equivalent functionality to multiple RIBs'. A=
20
 ] >> ] > > better wording, however not to
 ] >> ] > > 'bloated', welcome. I would however strongly disagree to even sugge
st=
 ] >> ] =20
 ] >> ] > > that things can be stored in the
 ] >> ] > > 'same' RIB in some special cases. Just too messy ...
 ] >> ] >=20
 ] >> ] > Exactly. In fact, I think it was a "SHOULD" or "MAY" at first, and
 ] >> ] > I suggested it is changed to a "MUST" for this very reason.
 ] >> ] 
 ] >> ] I still believe that "MUST" is introducing constraints that are outside
 t=
 ] >> ] he=20
 ] >> ] scope of this draft.
 ] >>
 ] >>I sort of agree with you that "SHOULD" is a better wording in this case.
 ] >>We advice people this should be the way to do things, but if someone has
 ] >>a creative mechanism also make it work, we probably don't care, its
 ] >>internal to the box.
 ] >>
 ] > thinking twice about it, ok, you guys have a point but please, under no 
 ] > circumstances suggest that
 ] > things could be in a single RIB but strongly direct in the direction of 
 ] > two cleanly disjoint RIBs.
 ] 
 ] >>
 ] >>
 ] >> ] 
 ] >> ] I believe this draft is intended to describe a way to build different S
PT=
 ] >> ] s,=20
 ] >> ] but not the way packet forwarding is done (as long as packets are forwa
rd=
 ] >> ] ed=20
 ] >> ] according to the SPT associated to a given MT)
 ] >> ] 
 ] >> ] s.
 ] >> ] =20
 ] >> > > As to overlaping address spaces, I agree that the draft is not enough
=
 ] >> ] =20
 ] >> ] > > but anything more (e.g.
 ] >> ] > > looking at stripped labels or other stuff to decide between RIBs) i
s =
 ] >> ] out=20
 ] >> ] > > of the scope of this document.
 ] >> ] >=20
 ] >> ] > I remember having the same concern when reviewing the first version
 ] >> ] > of this draft a year ago. Since I'm not the only one, what we could
 ] >> ] > probably do is describe (as opposed to specify) or enumerate mechanis
ms
 ] >> ] > that could potentially be used to associate an incoming packet with
 ] >> ] > a specific topology and RIB, i.e., a somewhat descriptive hint :)
 ] >>
 ] >>I also feel that the wording "additional mechanism MAY be used to resolve 
 ] >> the topology identity of the incoming IP packets on the interface."
 ] >>is a good enough hint. Since whatever more specific we hint, people don't
 ] >>have to follow; some implementation can come up a neat way to leave the
 ] >>hint obsolete. I personally don't see this "overlapping IP space on the
 ] >>same interface" is the way to use MT extensions.
 ] >>
 ] >>thanks.
 ] >>
 ] 
 ] > yepp, let's just hint, enumerations and solutions are outside scope of 
 ] > this draft
 ] 
 ] >     -- tony
 ] 
 ] >>
 ] >>
 ] 
 ] 

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 22:41:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19235
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 22:41:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22901;
	Sun, 4 Aug 2002 22:40:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22871
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 22:40:26 -0400 (EDT)
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19172
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 22:39:13 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59)
	id <Q1H1TJRT>; Sun, 4 Aug 2002 22:39:56 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB35015F3113@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'prz@net4u.ch'" <prz@net4u.ch>, isis-wg@ietf.org
Subject: RE: [Isis-wg] admin tags and p2p over ether not on the isis WG pa
	ge ...
Date: Sun, 4 Aug 2002 22:39:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Tony,

The last update was in April for
draft-martin-neal-policy-isis-admin-tags-05.txt.  I just took a look at it
and noticed that I missed the expiry date.  I can resubmit with the same
revision and just add the expiry date.  It is still in the directory, in any
case.

Regards,
-chris

-----Original Message-----
From: Tony Przygienda [mailto:prz@net4u.ch] 
Sent: Sunday, August 04, 2002 4:40 PM
To: isis-wg@ietf.org
Subject: [Isis-wg] admin tags and p2p over ether not on the isis WG page ...


Admin Tags seems to have expired or was it never submitted as ISIS draft?
Could the authors repost it pls. I thought the rough consensus was to 
take it on ? 

and where is

draft-ietf-isis-igp-p2p-over-lan-00.txt  ?? Unless the authors gave up on it
?


    thanks

    --tony



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Aug  4 23:18:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20001
	for <isis-archive@odin.ietf.org>; Sun, 4 Aug 2002 23:18:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24558;
	Sun, 4 Aug 2002 23:16:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24530
	for <isis-wg@optimus.ietf.org>; Sun, 4 Aug 2002 23:16:22 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19949
	for <isis-wg@ietf.org>; Sun, 4 Aug 2002 23:15:10 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g753Hj930998;
	Mon, 5 Aug 2002 05:17:45 +0200
Message-ID: <3D4DE9A6.60107@net4u.ch>
Date: Sun, 04 Aug 2002 19:57:42 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Martin, Christian" <cmartin@gnilink.net>
CC: isis-wg@ietf.org
Subject: Re: [Isis-wg] admin tags and p2p over ether not on the isis WG pa
 ge ...
References: <94B9091E1149D411A45C00508BACEB35015F3113@entmail.gnilink.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Martin, Christian wrote:

>Tony,
>
>The last update was in April for
>draft-martin-neal-policy-isis-admin-tags-05.txt.  I just took a look at it
>and noticed that I missed the expiry date.  I can resubmit with the same
>revision and just add the expiry date.  It is still in the directory, in any
>case.
>
>Regards,
>

you want to rename it so it makes it into the ISIS group ?

    - tony




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug  5 13:13:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22739
	for <isis-archive@odin.ietf.org>; Mon, 5 Aug 2002 13:13:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16232;
	Mon, 5 Aug 2002 13:13:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16193
	for <isis-wg@optimus.ietf.org>; Mon, 5 Aug 2002 13:13:04 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22645
	for <isis-wg@ietf.org>; Mon, 5 Aug 2002 13:11:52 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g75HES903627
	for <isis-wg@ietf.org>; Mon, 5 Aug 2002 19:14:28 +0200
Message-ID: <3D4EADC1.2040000@net4u.ch>
Date: Mon, 05 Aug 2002 09:54:25 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: isis-wg@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Isis-wg] checking on rough consensus ....
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Ladies & Gentlemen, we have the following draft (renamed personal
submission) coming in as official draft as it was discussed a 
while ago on the list.  Since the whole discussion
has happened a tad back, we wanted to make sure that we have (still)
rough consensus of the group 
that we should take it on as an official workgroup
item. In case no objections are raised, we will confirm the draft 
in 3 days

	
	thanks 


	-- chairs





Network Working Group                                   Christian Martin
INTERNET DRAFT                                 Verizon Internet Services
Expiration Date: January 2003                                  Brad Neal
                                                Broadwing Communications
                                                         Stefano Previdi
August 2002                                                Cisco Systems



     A Policy Control Mechanism is IS-IS Using Administrative Tags
                  <draft-ietf-isis-admin-tags-05.txt>


1. Status of this Memo

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

   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/1id-abstracts.txt

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


2. Abstract

   This document describes an extension to the IS-IS protocol to add
   operational capabilities that allow for ease of management and
   control over IP prefix distribution within an IS-IS domain.  The IS-
   IS protocol is specified in [1], with extensions for supporting IPv4
   specified in [2] and further enhancements for Traffic Engineering [4]
   in [3] and [6].

   This document enhances the IS-IS protocol by extending the
   information that a Intermediate System (IS) [router] can place in
   Link State Protocol Data Units (LSPs) as specified in [2].  This



Martin, Neal, Previdi    Expires January 2003                  [Page 1]





INTERNET DRAFT     draft-ietf-isis-admin-tags-05.txt        August 2002


   extension will provide operators with a mechanism to control IP
   prefix distribution throughout multi-level IS-IS domains.
   Additionally, the information can be placed in LSPs that have TLVs as
   yet undefined, if this information is used to convey the same meaning
   in these future TLVs as it is used in the currently defined TLVs.



3. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].


4. Introduction

   As defined in [2] and extended in [3], the IS-IS protocol may be used
   to distribute IP prefix reachibility information throughout an IS-IS
   domain.  The IP prefix information is encoded as TLV type 128 and 130
   in [2], with additional information carried in TLV 135 as specified
   in [3] and TLV 235 as defined in [6].  In particular, the extended IP
   Reachabilty TLV (135) contains support for a larger metric space, an
   up/down bit to indicate redistribution between different levels in
   the hierarchy, an IP prefix, and one or more sub-TLVs that can be
   used to carry specific information about the prefix.  TLV 235 is a
   derivative of TLV 135, with the addition of MultiTopology membership
   information [6].

   As of this writing no sub-TLVs have been defined; however, this draft
   proposes 2 new sub-TLVs for both TLV 135 and TLV 235 that may be used
   to carry administrative information about an IP prefix.


5. Sub-TLV Additions

   This draft proposes 2 new "Administrative Tag" sub-TLVs to be added
   to TLV 135 and 235.  These TLVs specify one or more ordered, 32 or 64
   bit unsigned integers that may be associated with an IP prefix.
   Example uses of these tags include controlling redistribution between
   levels and areas, different routing protocols, or multiple instances
   of IS-IS running on the same router, or carrying BGP standard or
   extended communites.

   The methods for which their use is employed is beyond the scope of
   this document and left to the implementer and/or operator.

   The encoding of the sub-TLV(s) is discussed in the following



Martin, Neal, Previdi    Expires January 2003                  [Page 2]





INTERNET DRAFT     draft-ietf-isis-admin-tags-05.txt        August 2002


   subsections.


5.1. 32-bit Administrative Tag Sub-TLV 1

   The Administrative Tag shall be encoded as one or more 4 octet
   unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The
   Administrative Tag Sub-TLV has following structure:

        1 octet of type (value: 1)
        1 octet of length (value: multiple of 4)
        one or more instances of 4 octets of administrative tag

   An implementation may consider only one of the encoded tags, in which
   case the first encoded tag must be considered.  A tag value of zero
   is reserved and should be treated as "no tag".


5.2. 64-bit Administrative Tag Sub-TLV 2

   The Administrative Tag shall be encoded as one or more 8 octet
   unsigned integers using Sub-TLV 2 in TLV-135 [3] and TLV 235 [6]. The
   64-bit Administrative Tag Sub-TLV has following structure:

        1 octet of type (value: 1)
        1 octet of length (value: multiple of 8)
        one or more instances of 8 octets of administrative tag

   An implementation may consider only one of the encoded tags, in which
   case the first encoded tag must be considered.  A tag value of zero
   is reserved and should be treated as "no tag".


6. Ordering of Tags

   The semantics of the tag order are implementation-dependent.  That
   is, there is no implied meaning to the ordering of the tags that
   indicates a certain operation or set of operations need be performed,
   based on the order of the tags.  Each tag SHOULD be treated as an
   autonomous identifier that MAY be used in policy to perform a policy
   action.  Whether or not tag A preceeds or succeeds tag B SHOULD not
   change the meaning of the tag set.  However, an implementation MAY
   wish to preserve tag ordering such that an ordered set of tags has
   meaning to the local policy.

   Each IS that receives an LSP with TLV(s) 135 and/or 235, that have
   associated SubTLV(s) 1 and/or 2, MAY operate on the tag values as
   warranted by the implementation.  If an implementation needs to



Martin, Neal, Previdi    Expires January 2003                  [Page 3]





INTERNET DRAFT     draft-ietf-isis-admin-tags-05.txt        August 2002


   change tag values, for example, at an area boundary, then the TLV(s)
   SHOULD be copied to the newly generated Level-1 or Level-2 LSP at
   which point, the contents of the SubTLV(s) MAY change as dictated by
   the policy action.  In the event that no change is required, the
   SubTLV(s) SHOULD be copied in order into the new LSP, such that
   ordering is preserved.


7. A compliant IS-IS implementation:

   MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or
   235.

   MAY be able to assign more than one tag to any IP prefix in TLV(s)
   135 and/or 235.

   MAY be able to rewrite or remove one or more tags associated with a
   prefix in TLV(s) 135 and/or 235 upon LSP generation at an area
   boundary.


8. Operation

   An administrator associates an Administrative Tag value with some
   interesting property.  When IS-IS advertises reachability for some IP
   prefix that has that property, it adds the Administrative Tag to the
   IP reachability information TLV for that prefix, and the tag "sticks"
   to the prefix as it is flooded throughout the routing domian.

   Consider the network in figure 1. We wish to "leak" L1 prefixes [5]
   with some property, A, from L2 to the L1 router R1.  Without policy-
   groups, there is no way for R2 to know property A prefixes from
   property B prefixes.



                    R2--------R3--------R4
             L2     /                    \         
             - - - /- - - - - - - - - - - - - -
             L1   /                        \              
                R5----1.1.1.0/24 (A)       R5
                                            |
                                            |
                                      1.1.2.0/24 (B)


                           Figure 1




Martin, Neal, Previdi    Expires January 2003                  [Page 4]





INTERNET DRAFT     draft-ietf-isis-admin-tags-05.txt        August 2002


   We associate Administrative Tag 100 with property A, and have R5
   attach that value to the IP extended reachability information TLV for
   prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with
   Administrative Tag 100, and leak to L1."

   The previous example is rather simplistic; it seems that it would be
   just as easy for R2 simply to match the prefix 1.1.1.0/24. However,
   if there are a large number of routers that need to apply some policy
   according to property A and large number of "A" prefixes, this
   mechanism can be quite helpful.



9. Security Considerations

   This document raises no new security issues for IS-IS, as any
   annotations to IP prefixes should not pass outside the administrative
   control of the network operator of the IS-IS domain.  Such an
   allowance would violate the spirit of Interior Gateway Protocols in
   general and IS-IS in particular.


10. IANA Considerations

   The authors have chosen "1" as the typecode of the 32-bit
   Administrative Tag sub-TLV and "2" as the typecode of the 64-bt
   Administrative Tag SubTLV.  These values must be allocated by IANA.


11. Acknowledgments

   The authors would like to thank Henk Smit for clarifying the best
   place to describe this new information, Tony Li and Tony Przygienda
   for useful comments on this draft, Danny McPherson for some much
   needed formatting assistance, and Mike Shand for useful discussions
   on encoding structure of the sub-TLV.















Martin, Neal, Previdi    Expires January 2003                  [Page 5]





INTERNET DRAFT     draft-ietf-isis-admin-tags-05.txt        August 2002


12. References

   [1] "Intermediate System to Intermediate System Intra-Domain Routeing
       Exchange Protocol for use in Conjunction with the Protocol for
       Providing the Connectionless-mode Network Service (ISO 8473)",
       ISO 10589.

   [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and
       dual environments", RFC 1195, December 1990.

   [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering",
       Internet Draft, "Work in Progress", September 2000.

   [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus,
       J., "Requirements for Traffic Engineering Over MPLS," RFC 2702,
       September 1999.

   [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution
       with Two-Level IS-IS" RFC 2966, October 2000

   [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology
       Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April
       2002.



13. Authors' Address

   Christian Martin
   Verizon Internet Services
   1880 Campus Commons Dr
   Reston, VA 20191
   Email: cmartin@gnilink.net

   Brad Neal
   Broadwing Communications
   1835 Kramer Lane - Suite 100
   Austin, TX 78758
   USA
   Email: bneal@broadwing.com

   Stefano Previdi
   Cisco Systems, Inc.
   De Kleetlaan 6A
   1831 Diegem - Belgium
   email: sprevidi@cisco.com


Martin, Neal, Previdi    Expires January 2003                  [Page 6]




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug  5 16:03:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29757
	for <isis-archive@odin.ietf.org>; Mon, 5 Aug 2002 16:03:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26744;
	Mon, 5 Aug 2002 16:03:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26716
	for <isis-wg@optimus.ietf.org>; Mon, 5 Aug 2002 16:03:37 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29722
	for <isis-wg@ietf.org>; Mon, 5 Aug 2002 16:02:23 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57BDC@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
Subject: [Isis-wg] Level in IPRA Table
Date: Mon, 5 Aug 2002 16:02:58 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

> I don't see any problem [with configuring levels]
> if the Type of IPRA Entries are Manual as you said,
> but if the IPRAs are of type automatic and if they 
> are learnt from an another routeing protocol, then 
> how could we decide about level?

> suryanarayana

Suryanarayana -
	This is a good point.  

Ruminating out loud, I see a couple of options

	1) For an automatic route, give the (lowest) level on which the
route leaked in

	2) have a field that takes values such as

		automatic
		configL1
		configL2

- jeff parker
- axiowave networks

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug  6 00:59:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15772
	for <isis-archive@odin.ietf.org>; Tue, 6 Aug 2002 00:59:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23084;
	Tue, 6 Aug 2002 00:58:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23054
	for <isis-wg@optimus.ietf.org>; Tue, 6 Aug 2002 00:58:31 -0400 (EDT)
Received: from WS0005.indiatimes.com ([203.199.93.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15726
	for <isis-wg@ietf.org>; Tue, 6 Aug 2002 00:57:17 -0400 (EDT)
Received: from 192.168.57.15 (a2 [192.168.57.22])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id KAA13302;
	Tue, 6 Aug 2002 10:21:55 +0530
From: "appallar" <appallar@indiatimes.com>
Message-Id: <200208060451.KAA13302@WS0005.indiatimes.com>
To: "Jeff Parker"<jparker@axiowave.com>, "ISIS-WG E-mail"<isis-wg@ietf.org>
Reply-To: "appallar"<appallar@indiatimes.com>
Subject: Re: [Isis-wg] Level in IPRA Table
Date: Tue, 06 Aug 2002 10:30:29 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20028621030291477171087"
MIME-Version: 1.0
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

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

Hello All,


 I Feel the second option is better, which is inclusive of the first one. We can have a configurable object in system Table for choosing the Level of Automatic IPRAs with the default value of automatic.


 


Thanks and Regards


suryanarayana

"Jeff Parker" wrote:



&gt; I don't see any problem [with configuring levels]
&gt; if the Type of IPRA Entries are Manual as you said,
&gt; but if the IPRAs are of type automatic and if they 
&gt; are learnt from an another routeing protocol, then 
&gt; how could we decide about level?

&gt; suryanarayana

Suryanarayana -
This is a good point. 

Ruminating out loud, I see a couple of options

1) For an automatic route, give the (lowest) level on which the
route leaked in

2) have a field that takes values such as

automatic
configL1
configL2

- jeff parker
- axiowave networks

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

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

<P>Hello All,</P>
<P>&nbsp;I Feel the second option is better, which is inclusive of the first one. We can have a configurable object in system Table for choosing the Level of Automatic IPRAs with the default value of automatic.</P>
<P>&nbsp;</P>
<P>Thanks and Regards</P>
<P>suryanarayana<BR><BR><B><I>"Jeff Parker"<JPARKER@AXIOWAVE.COM></B></I> wrote:<BR><BR></P>
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><BR>&gt; I don't see any problem [with configuring levels]<BR>&gt; if the Type of IPRA Entries are Manual as you said,<BR>&gt; but if the IPRAs are of type automatic and if they <BR>&gt; are learnt from an another routeing protocol, then <BR>&gt; how could we decide about level?<BR><BR>&gt; suryanarayana<BR><BR>Suryanarayana -<BR>This is a good point. <BR><BR>Ruminating out loud, I see a couple of options<BR><BR>1) For an automatic route, give the (lowest) level on which the<BR>route leaked in<BR><BR>2) have a field that takes values such as<BR><BR>automatic<BR>configL1<BR>configL2<BR><BR>- jeff parker<BR>- axiowave networks<BR><BR>_______________________________________________<BR>Isis-wg mailing list<BR>Isis-wg@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/isis-wg</BLOCKQUOTE><BR>
<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, Audio-Books and Music Accessories from <A href="http://www.planetm.co.in">http://www.planetm.co.in</A>

--=_MAILER_ATTACH_BOUNDARY1_20028621030291477171087--


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug  7 23:44:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19720
	for <isis-archive@odin.ietf.org>; Wed, 7 Aug 2002 23:44:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26027;
	Wed, 7 Aug 2002 23:38:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25999
	for <isis-wg@optimus.ietf.org>; Wed, 7 Aug 2002 23:38:54 -0400 (EDT)
Received: from titanium ([65.223.109.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19579
	for <isis-wg@ietf.org>; Wed, 7 Aug 2002 23:37:39 -0400 (EDT)
Received: from titanium ([127.0.0.1] helo=titanium.ipinfusion.com)
	by titanium with esmtp (Exim 3.35 #1 (Debian))
	id 17ce8C-0006m8-00
	for <isis-wg@ietf.org>; Wed, 07 Aug 2002 20:38:36 -0700
Date: Wed, 07 Aug 2002 20:38:35 -0700
Message-ID: <878z3inhok.wl@ipinfusion.com>
From: Noguchi Kay <kay@ipinfusion.com>
To: isis-wg@ietf.org
User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Subject: [Isis-wg] isisISAdjAreaAddrTable IS-IS MIB, isisISAdjAreaAddress for index?
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Hi Jeff,

This is Kay.

I encountered one question regarding isisISAdjAreaAddrEntry index in the
draft-ietf-isis-wg-mib-08.txt.

Draft says this entry has five indexes as shown below but I think we don't
have to have isisISAdjAreaAddress as index. We can specify one
isisISAdjAreaAddrEntry by just only four indexes, without isisISAdjAreaAddress.

Can we omit this isisISAdjAreaAddress from indexes for isisISAdjAreaAddrEntry?

     isisISAdjAreaAddrEntry OBJECT-TYPE
         SYNTAX IsisISAdjAreaAddrEntry
         MAX-ACCESS not-accessible
         STATUS current
         DESCRIPTION
             "Each entry contains one Area Address reported by a
             neighboring Intermediate System in its IIH PDUs."
         INDEX { isisSysInstance,
                 isisCircIndex,
                 isisISAdjIndex,
                 isisISAdjAreaAddrIndex,
                 isisISAdjAreaAddress }
     ::= { isisISAdjAreaAddrTable 1 }

Thanks in advance,

								kay


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug  8 03:20:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03153
	for <isis-archive@odin.ietf.org>; Thu, 8 Aug 2002 03:20:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13261;
	Thu, 8 Aug 2002 03:20:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13235
	for <isis-wg@optimus.ietf.org>; Thu, 8 Aug 2002 03:20:10 -0400 (EDT)
Received: from titanium (adsl-63-198-41-106.dsl.snfc21.pacbell.net [63.198.41.106])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03092
	for <isis-wg@ietf.org>; Thu, 8 Aug 2002 03:18:57 -0400 (EDT)
Received: from titanium ([127.0.0.1] helo=titanium.ipinfusion.com)
	by titanium with esmtp (Exim 3.35 #1 (Debian))
	id 17chad-00077O-00
	for <isis-wg@ietf.org>; Thu, 08 Aug 2002 00:20:11 -0700
Date: Thu, 08 Aug 2002 00:20:11 -0700
Message-ID: <871y99olzo.wl@ipinfusion.com>
From: Noguchi Kay <kay@ipinfusion.com>
To: isis-wg@ietf.org
User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Subject: [Isis-wg] isisISAdjProtSuppEntry index
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Hi Jeff again,

This is Kay.

I have another question, this time is isisISAdjProtSuppEntry.
Current draft says we have four indexes shown below but I think this is
not good enough. We should have isisISAdjIndex like other isisISAdj*Entries
and we doesn't need isisISAdjProtSuppProtocol as index.

     isisISAdjProtSuppEntry OBJECT-TYPE
         SYNTAX IsisISAdjProtSuppEntry
         MAX-ACCESS not-accessible
         STATUS current
         DESCRIPTION
             "Each entry contains one protocol supported by a
             neighboring Intermediate System as reported in its IIH
             PDUs."
         INDEX {  isisSysInstance,
             isisCircIndex,
             isisISAdjProtSuppIndex,
             isisISAdjProtSuppProtocol }
     ::= { isisISAdjProtSuppTable 1 }

So we should change isisISAdjProtSuppEntry's index like below.
Can we?

     isisISAdjProtSuppEntry OBJECT-TYPE
         SYNTAX IsisISAdjProtSuppEntry
         MAX-ACCESS not-accessible
         STATUS current
         DESCRIPTION
             "Each entry contains one protocol supported by a
             neighboring Intermediate System as reported in its IIH
             PDUs."
         INDEX {  isisSysInstance,
                  isisCircIndex,
                  isisISAdjIndex,
                  isisISAdjProtSuppIndex }
     ::= { isisISAdjProtSuppTable 1 }

Thank you,

								kay

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug 12 19:42:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14807
	for <isis-archive@odin.ietf.org>; Mon, 12 Aug 2002 19:42:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17530;
	Mon, 12 Aug 2002 19:41:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17501
	for <isis-wg@optimus.ietf.org>; Mon, 12 Aug 2002 19:41:11 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14756
	for <isis-wg@ietf.org>; Mon, 12 Aug 2002 19:39:54 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 395A039B5B3; Mon, 12 Aug 2002 16:41:03 -0700 (PDT)
To: prz@net4u.ch
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ... 
In-reply-to: Mail from Tony Przygienda <prz@net4u.ch> 
 dated Thu, 25 Jul 2002 23:14:23 PDT
 <3D40E8BF.4030209@net4u.ch> 
Date: Mon, 12 Aug 2002 16:41:03 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020812234103.395A039B5B3@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


 ] Dave indicated that he felt the rough consensus was to not take it on as 
 ] workgroup item. Any contradicting opinions please to the mailing list.
 ] 

I obviously have some "contradicting opinions", sorry forgot to
respond to this email thread sooner. I think we need to ask ourselves
that:

  1) if there is a problem?
  2) if yes, then if this is the right approach?

For the first one, I think we currently don't have enough information
in the IGP to effectively troubleshoot adjacency problems, and IGP
adjacency is an important part of network stability. I often get
reports asking routerX adjacencyY was down two hours ago, why? My
response usualy would be: I don't know why. It could be routerX had
problem, or it's neighbors, or it could be protocol packets were
dropped due to congestion somewhere. If we can know where the
problem is, then we might know the solutions either in improving
network design, changing configuration, or tuning implementation.
This sequence number scheme gives us: a) it indicates clearly if
there is protocol packet loss; b) (not currently in the draft, but
should be added) it indicates if neighbors send us IIH on time.
c) (optionally) base on "a" and "b", an implementation can optionally
adjust the holddown in order to avoid a premature adjacency bounce.

This seq# sheme can also help ISPs to determine good configuration
settings on routers. For example, we always wondering: how low should
we set the holddown time(hello-interval plus the multiplier). If we
have a history of IIH loss stats plus the neighbors IIH slip history,
then it's an easy task to determin intervals among the adjacencies
on specific interfaces.

For the second question, my opinion is that, this seq# scheme is
a very simple mechanism, very cheap in terms of implementation and
router resources. also, it does not have to be a "always-on" scheme,
it can be turned on as needed if so desired by implementations.
i don't buy the argument that this can be accompulished by utilities
such as "telnet" or "snmp";

An alternative of course can be a new and generic "link adjacency"
protocol which is not specific to isis or ospf. I think
unless IGP/LDP/etc can use this new "link adjacency" protocol or
piggyback on this protocol, there is an extra hello protocol on
the router needs to be maintained, that may not be a good thing;
also the relation of this new protocol and IGP adjacency problem
is an indirect one, its not as good as the information is within
the IGP itself. For example, if this new protocol delays sending
out packets for a couple of minutes does not necessarily mean
the IGP process also delays for that long. Since this seq# mechanism
is so cheap, why not use it now.

again, we welcome for the discussions on this topic and we want
to ask the working group to accept this as wg document.

thanks.

 ] >
 ] >
 ] > 9) adding Sequence Ids to Hello packets
 ] >
 ] >    Discussion prior to presentation:
 ] >     Chair requested the number of people who read draft: 10 (estimate)
 ] >     Chair determined we should go on to discuss the draft.
 ] >
 ] >    IIH sequence number
 ] >
 ] >    motivation: 1) large of adjacencies
 ] >                2) hold-down timer is low for fast convergence
 ] >            3) congestion over the link
 ] >            4) router process scheduling slips
 ] >            5) massive LSP flooding
 ] >
 ] >     Who's fault is the fluctuation of the links.
 ] >
 ] >   Addition:  new TLV in Hello packet that has sequence number
 ] >
 ] >   Benefit:
 ] >       1) p2mp - if only one receiving router has seq# skips,
 ] >         probably an inbound congestion issues;
 ] >
 ] >         if all the receiving routes for the same router have
 ] >          seq # skips, probably the sender is not sending out
 ] >         the hello packet at the same time
 ] >
 ] >       2) [need the rest of the information here]
 ] >
 ] >
 ] >    purpose:
 ] >      1) mostly NM usage
 ] >      2) adjust the hold time timer to prevent premature adjacency flap
 ] >
 ] >
 ] >     format of the TLV:  Code: 241
 ] >             length: 4 octets
 ] >             value: a 32 bit unsigned number, 0xfffffff[all ones] reserved
 ] >
 ] >       Each level needs to keep sequence number space.
 ] >
 ] >     discussion from list: sub-TLV - for this sequence number is 
 ] > expendable
 ] >               sub-tlv - to indicate time lasp since last IIH or % of 
 ] > interval
 ] >                     this is symmetrical to the sequence # skip for auto
 ] >                     hold-down time adjust.  If one knows the neighbor has
 ] >                     repeated scheduling slips, it an optionally do 
 ] > something
 ] >                     to prevent an adjacency flap
 ] >
 ] >    request: to be a working group
 ] >    Decision:  this draft is not ready to be working group draft
 ] >
 ] >    Discussion:  We do not need sequence IDs to add to hello packets.
 ] >
 ] >         If you receive packets and not other, it may be important to 
 ] > drop the packets.
 ] >
 ] >         [Naiming shen]  It is not a protocol, but an implementation 
 ] > issue on how
 ] >                 to determine the link is down.
 ] >
 ] >         If you have lots of interfaces on the box, you minimize the 
 ] > hello packet
 ] >         processing.
 ] >
 ] >         [Naiming shen]  That's one opinion. Another is send as fast as 
 ] > possible.
 ] >                 This proposal is very simple and does not take much time.
 ] >
 ] >         [Stephen] This is trouble shooting the link and the box.
 ] >
 ] >         [namining shen] We do not have the tools today, and this gives 
 ] > some additional
 ] >                     tools.  It is not a high price.  authentiation
 ] >
 ] >         [Stephen] This is a high price for the additional tool.
 ] >
 ] >         [Ed Kern] this is cranking the complexity knob to solve an 
 ] > edge problem.
 ] >
 ] >         [Naiming Shen] - This is a configuration problem. This is very 
 ] > cheap tradeoff
 ] >                  for trouble-shooting.
 ] >
 ] >         [Ed kern] authentication is required.  This doesn't tell you 
 ] > what the problem
 ] >               is exactly it.  I feel the complexity is increased?
 ] >
 ] >         [Amir] As a sequence number, it is cheap.  However, this is 
 ] > may not be
 ] >             the right direction.  This focus on the link protocols 
 ] > should not
 ] >             come from the is-is working group.  This focus should come 
 ] > from
 ] >             another working group.
 ] >
 ] >         [naiming] A problem on the adjacency is urgent due to fast 
 ] > convergence issues.
 ] >
 ] >         [dave] - You are assuming a trust model with the adjacencies; you
 ] >              have
 ] >
 ] >         [kareeti/dave] It is less expensive to use telnet to debug.
 ] >
 ] >         [xxx] replay attack is a concern. [dave ward] IP sec protects 
 ] > against
 ] >             this feature.  Any additions should await the RP-Sec 
 ] > information.
 ] >
 ] >         [Dorian Kim] This has a good feature, but there are other 
 ] > existing tool that can solve this problem in a network.  As operators 
 ] > we have enough  crud in the routing code.  This feature does not 
 ] > really buy you enoug to add more complexity to the routing system.
 ] 
 ] 
 ] Dave indicated that he felt the rough consensus was to not take it on as 
 ] workgroup item. Any contradicting opinions please to the mailing list.
 ] 

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug 12 21:20:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16730
	for <isis-archive@odin.ietf.org>; Mon, 12 Aug 2002 21:20:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21915;
	Mon, 12 Aug 2002 21:19:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21886
	for <isis-wg@optimus.ietf.org>; Mon, 12 Aug 2002 21:19:08 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16661
	for <isis-wg@ietf.org>; Mon, 12 Aug 2002 21:17:50 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7D1ITm18430;
	Mon, 12 Aug 2002 18:18:30 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7D1ITX60701;
	Mon, 12 Aug 2002 18:18:29 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Mon, 12 Aug 2002 18:18:29 -0700 (PDT)
Message-Id: <200208130118.g7D1ITX60701@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: naiming@redback.com
CC: prz@net4u.ch, isis-wg@ietf.org
In-reply-to: <20020812234103.395A039B5B3@prattle.redback.com> (message from
	Naiming Shen on Mon, 12 Aug 2002 16:41:03 -0700)
Subject: Re: [Isis-wg] Meeting minutes ...
References:  <20020812234103.395A039B5B3@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

This option is pretty low-overhead, but as such it is also
semantically challenged.  It seems to be most useful on true
multipoint circuits, but the number of those as a percentage of the
ISIS-enabled interfaces in the world would seem to be a small
minority.

If ISIS implementations are done properly, Hellos should not languish
in queues, the incidence of late Hellos (which, after all, typically
average 12.5% *early*) should be roughly zero, and long run-times
affecting adjacency maintenance should also be a thing of the past in
the dominant implementations (if I understand what the Other Guys are
doing.)  Hello drops should thus be detectable on a statistical basis
by measuring the interarrival time and ought to be independent of
router CPU load.

I don't see how this is useful in practice for tuning the hello
protocol in any case.  Adjacency drops are deeply anomalous events,
often with very steep onset, and the anomalies are not predictable.
Implementations in which adjacency stability depends on CPU load or
latency are doomed to collapse catastrophically sooner or later, and
trying to be clever about tuning will likely only move you closer to
the cliff.  Those which are independent won't measure much of anything
interesting, since they should only start to reliably drop hellos only
when the hello processing dominates the CPU, which is an untenable
regime in which to operate.

This would seem to reduce the proposal to a form of link quality detection,
which really ought not be part of ISIS.

My two kopeks...

--Dave

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug 12 23:32:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19654
	for <isis-archive@odin.ietf.org>; Mon, 12 Aug 2002 23:32:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28636;
	Mon, 12 Aug 2002 23:30:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28600
	for <isis-wg@optimus.ietf.org>; Mon, 12 Aug 2002 23:30:41 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19584
	for <isis-wg@ietf.org>; Mon, 12 Aug 2002 23:29:23 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g7D3W1913515;
	Tue, 13 Aug 2002 05:32:01 +0200
Message-ID: <3D58789F.3030907@net4u.ch>
Date: Mon, 12 Aug 2002 20:10:23 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Katz <dkatz@juniper.net>
CC: naiming@redback.com, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ...
References: <20020812234103.395A039B5B3@prattle.redback.com> <200208130118.g7D1ITX60701@cirrus.juniper.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Dave Katz wrote:

>This option is pretty low-overhead, but as such it is also
>semantically challenged.  
>
<chair hat off>
agreed that it is kind of hard to grasp one's head around what it really 
measures. It is a loss number
delivered by probes stuck into two not very clearly defined points in 
two boxes and/or
probably the link inbetween. But somehow the idea seems intriguing, kind 
of like
peeking at TCP window size, it's an unclear number but indicative of the 
aggregate
network behavior.

>
>
>If ISIS implementations are done properly, Hellos should not languish
>in queues, the incidence of late Hellos (which, after all, typically
>average 12.5% *early*) should be roughly zero, and long run-times
>affecting adjacency maintenance should also be a thing of the past in
>the dominant implementations (if I understand what the Other Guys are
>doing.)  Hello drops should thus be detectable on a statistical basis
>by measuring the interarrival time and ought to be independent of
>router CPU load.
>
hmmm, I think your assertion that hellos will not languish in queues is 
a little bit of a jump.
Even in an excellent implementation with a nice load-shedding, once you 
get to the point
where you cannot minimally process things real-time (maybe your box
is doing plenty high priority other stuff and you have so many 
adjacencies that just
sorting things in and out into proper queues/processes/tasks takes 
serious time and maybe
the whole thing is only transitory), all kind of trade-offs
exist as to drop vs. queue. Nothing surprising there, store-and-forward 
vs. hot-potato
vs. preventive drop strategies, every overprovisioned system in control 
theory is in the
same space. So things may languish in queues some and if they share 
queues, those
queues can grow long. But maybe I completely misunderstood what you are 
trying to say.

>
>
>I don't see how this is useful in practice for tuning the hello
>protocol in any case.  Adjacency drops are deeply anomalous events,
>often with very steep onset, and the anomalies are not predictable.
>
Hmm, I tend to slightly disagree here. If you take just ISIS in a box 
and you load it
up smoothly with more and more adjacencies, properly designed 
load-shedding will
start to show a nice increase in drop rate from a certain point in time 
that will be
probabilistically measurable and then such a scheme would allow you to 
get the
probability numbers you need.  However, for an implementation that sheds 
based on
'over X% CPU load, I drop ALL the hello packets' it will be useless. 
Guess my point is,
without having a 'model' of an implementation we can agree on, we may be 
writing
lots of e-mails without ever communicating.

>
>Implementations in which adjacency stability depends on CPU load or
>latency are doomed to collapse catastrophically sooner or later, and
>trying to be clever about tuning will likely only move you closer to
>the cliff.  
>
yes, at a ceratin point in time _any_ implementation that takes an 
arbitrary amount of
adjacencies will collapse, be it based on CPU overload or by capping off 
the amount
of adjacencies to protect from CPU overload (but even then it will 
collapse, it's a well-known
control theory thing, if you need to classify your input, your system 
will melt at ceratin
point in time).   By collapse I mean ' it does not serve all adjacencies 
anymore '.

>Those which are independent won't measure much of anything
>interesting, since they should only start to reliably drop hellos only
>when the hello processing dominates the CPU, which is an untenable
>regime in which to operate.
>
yes, we're in sync here but this is a softer solution space than you 
make it sound.
An implementation could say 'I do hellos and start to drop them from a 
certain queue
length on and I always serve some flooding at lower priority. Once I see 
unatainable amount of
drop statistically per adjacency, I start to be lazier and lazier with 
flooding'. Yes, it's playing the edge
I do _not_ think is worth playing but then this number could be usefull. 
 In principle I guess
I agree with you that optimizing the implementation to the point where 
you start to
walk the chaos boundary *(which this thing ultimately is a tool for) is 
not worth in
this kind of protocols.

>This would seem to reduce the proposal to a form of link quality detection,
>which really ought not be part of ISIS.
>
yes, that's the main danger here, we start to build link-monitor things 
into a routing protocol
and that has a high potential to embarass us later ...

I guess I'm neither for nor vs. this thing but I find the discussion 
somehow intriguing.

    -- tony



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Aug 12 23:43:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19970
	for <isis-archive@odin.ietf.org>; Mon, 12 Aug 2002 23:43:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29194;
	Mon, 12 Aug 2002 23:40:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29164
	for <isis-wg@optimus.ietf.org>; Mon, 12 Aug 2002 23:40:16 -0400 (EDT)
Received: from web21105.mail.yahoo.com (web21105.mail.yahoo.com [216.136.227.107])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19800
	for <isis-wg@ietf.org>; Mon, 12 Aug 2002 23:38:59 -0400 (EDT)
Message-ID: <20020813034015.34826.qmail@web21105.mail.yahoo.com>
Received: from [212.179.34.114] by web21105.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 20:40:15 PDT
Date: Mon, 12 Aug 2002 20:40:15 -0700 (PDT)
From: Nagasta Bagamba <nagastabagamba@yahoo.com>
To: isis-wg@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Isis-wg] IGP shortcuts using LDP
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Hi all,
This mail regards to IGP shortcuts. I read the draft
draft-hsmit-mpls-igp-spf-00.txt. It talks about IGP
shortcuts using TE/RSVP.
My question is - is there such a thing as IGP
shortcuts
using LDP LSPs ?
It seems like there is no justification for that (as
LDP is probably using IGP to build its LSPs).
Does anyone know about use/implementation of this
issue by any vendor ?
 
Regards,
Nagi




__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 01:34:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22550
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 01:34:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13133;
	Tue, 13 Aug 2002 01:33:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13101
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 01:33:02 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22483
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 01:31:44 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id EF5E718D3E5; Mon, 12 Aug 2002 22:33:00 -0700 (PDT)
To: Dave Katz <dkatz@juniper.net>
Cc: prz@net4u.ch, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ... 
In-reply-to: Mail from Dave Katz <dkatz@juniper.net> 
 dated Mon, 12 Aug 2002 18:18:29 PDT
 <200208130118.g7D1ITX60701@cirrus.juniper.net> 
Date: Mon, 12 Aug 2002 22:33:00 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020813053300.EF5E718D3E5@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


Dave,
	thanks for the comments. see replies in inline.

 ] This option is pretty low-overhead, but as such it is also
 ] semantically challenged.  It seems to be most useful on true
 ] multipoint circuits,

even though the draft discussed more cases in LAN, but if the
time info is added to the seq# scheme, it should help both cases.

 ] but the number of those as a percentage of the
 ] ISIS-enabled interfaces in the world would seem to be a small
 ] minority.

it's true that these days, it seems more p2p links for network
interconnections. but the multi-point media is not going away,
some of them even come back(e.g. RPR).

 ] 
 ] If ISIS implementations are done properly, Hellos should not languish
 ] in queues, the incidence of late Hellos (which, after all, typically
 ] average 12.5% *early*) should be roughly zero, and long run-times
 ] affecting adjacency maintenance should also be a thing of the past in
 ] the dominant implementations (if I understand what the Other Guys are
 ] doing.)

now you have made a couple of assumptions:

  - vendors always implementation them properly without cut corners
    for both yourself and your neighbors
  - users are dealing with very reasonable number of adjacencies
  - users are using very "normal" holddown time

but I think this draft are dealing with "problems", especially in
the cases where one of the above may not be true. Even you trust
yourself, how do you prove it is really your neighbor's problem?
the hard thing for troubleshoot adjacency problem is that, either
side can do something wrong.

 ]  Hello drops should thus be detectable on a statistical basis
 ] by measuring the interarrival time and ought to be independent of
 ] router CPU load.

i doubt this is always true. you can know from statistical point
of view if there is packet being dropped, but you can never be
sure it IS dropped or not. what prevents an implementation to
send IIH multiple times during a statistical interval? not much.
just from recording point of view, there is not much you can say
about protocol packets loss or not, especially if the packet loss
rate is small.

 ] 
 ] I don't see how this is useful in practice for tuning the hello
 ] protocol in any case.

Let me just give some examples:

 - some ISPs used to set holddown time rather long, say 1.5 minutes.
   so the questions is with so much changes since the people invented
   this 1.5 minutes number, is it safe to lower it? lower to what?
   with this seq# scheme, it at least give you some history when a
   user start to change the numbers. is there packet loss during the
   busy hours, network churn times, is neighbor's IIH usually sent
   on time, offset by how much? If one has those numbers, they can
   take the conservative approach by setting it to a very safe value.

 - normally, as you mentioned, if the IIH packets are handled properly,
   the loss, delay probability is not high. but in some cases when
   there is large number of adjs or very fast hellos, how much buffer
   space is enough? I'm not proposing to run with huge number of adjs
   or tune down the iih hold time to extreme low, but those things does
   impact the protocol implementations.

 - when vendors/customers do the IGP scalability testing, what do they
   do if the adjacencies start to drop? just stop? that's fine. but there
   maybe some silly mistakes in the code caused this. If you can have
   more info on what's going on, you can get rid of next round of
   bottlenecks to push those numbers further. those data helps to
   implement protocols better.

 ]  Adjacency drops are deeply anomalous events,
 ] often with very steep onset, and the anomalies are not predictable.
 ] Implementations in which adjacency stability depends on CPU load or
 ] latency are doomed to collapse catastrophically sooner or later, and
 ] trying to be clever about tuning will likely only move you closer to
 ] the cliff. 

what your saying is mostly true. but seq# miss, sending time slip
may not necessary mean adjacency drops. If you have high number
of multipliers, maybe it's perfectly ok to have those misses. But
it is also nice to know if there is miss or not, this will be the
first indication to the users/testers of something is stretched too far.

 ] Those which are independent won't measure much of anything
 ] interesting, since they should only start to reliably drop hellos only
 ] when the hello processing dominates the CPU, which is an untenable
 ] regime in which to operate.

I'm not suggest people should detect the boundary, then just set the
settings on those boundaries. I'm saying its nice to know those boudaries,
also users can intelligently use those data to set their comfortable
numbers.

 ] 
 ] This would seem to reduce the proposal to a form of link quality detection,
 ] which really ought not be part of ISIS.

I don't think this seq# scheme is just here for detect line noise or
link congestions. But if we do believe that vendors always implement
properly, or we will only handle some "reasonable" numbers, then I
do agree that there is no place for this scheme.

thanks.

 ] 
 ] My two kopeks...
 ] 
 ] --Dave

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 02:01:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25471
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 02:01:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14833;
	Tue, 13 Aug 2002 02:02:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14795
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 02:02:02 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24010
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 02:00:44 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 3E610CAB6B; Mon, 12 Aug 2002 23:02:01 -0700 (PDT)
To: prz@net4u.ch
Cc: Dave Katz <dkatz@juniper.net>, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ... 
In-reply-to: Mail from Tony Przygienda <prz@net4u.ch> 
 dated Mon, 12 Aug 2002 20:10:23 PDT
 <3D58789F.3030907@net4u.ch> 
Date: Mon, 12 Aug 2002 23:02:01 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020813060201.3E610CAB6B@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


Tony,

agree with most of your comments.

 ] 
 ] >This would seem to reduce the proposal to a form of link quality detection,
 ] >which really ought not be part of ISIS.
 ] >
 ] yes, that's the main danger here, we start to build link-monitor things 
 ] into a routing protocol
 ] and that has a high potential to embarass us later ...

at least the "iih sending time slip" data has nothing to do with
"link-monitor" things:-) even if this did reduce to a "link-monitoring"
mechanism, this is for our protocol use as long as there is no such
things exist to use, so i don't feel there is something to be embarassed.

thanks.

 ] 
 ] I guess I'm neither for nor vs. this thing but I find the discussion 
 ] somehow intriguing.
 ] 
 ]     -- tony
 ] 
 ] 

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 03:16:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03536
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 03:16:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18702;
	Tue, 13 Aug 2002 03:16:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18671
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 03:16:32 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03472
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 03:15:13 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 7BBC939B5B6; Tue, 13 Aug 2002 00:16:30 -0700 (PDT)
To: Nagasta Bagamba <nagastabagamba@yahoo.com>
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] IGP shortcuts using LDP 
In-reply-to: Mail from Nagasta Bagamba <nagastabagamba@yahoo.com> 
 dated Mon, 12 Aug 2002 20:40:15 PDT
 <20020813034015.34826.qmail@web21105.mail.yahoo.com> 
Date: Tue, 13 Aug 2002 00:16:30 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020813071630.7BBC939B5B6@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

 ] Hi all,
 ] This mail regards to IGP shortcuts. I read the draft
 ] draft-hsmit-mpls-igp-spf-00.txt. It talks about IGP
 ] shortcuts using TE/RSVP.
 ] My question is - is there such a thing as IGP
 ] shortcuts
 ] using LDP LSPs ?
 ] It seems like there is no justification for that (as
 ] LDP is probably using IGP to build its LSPs).
 ] Does anyone know about use/implementation of this
 ] issue by any vendor ?

I don't know anyone has "implemented" that. The shortcut is
useful for TE/RSVP LSPs because there is no other dynamic
way to direct traffic using those tunnels besides to match the
recursive endpoint of the tunnel itself. For LDP, the
purpose of the protocol is to tell you how to direct traffic
through those LSPs. If one decides to alter those, then
it runs to the risk of forwarding loops since the LDP tunnels
are not source routed.

cheers.

 ]  
 ] Regards,
 ] Nagi
 ] 
 ] 
 ] 
 ] 
 ] __________________________________________________
 ] Do You Yahoo!?
 ] HotJobs - Search Thousands of New Jobs
 ] http://www.hotjobs.com
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] Isis-wg@ietf.org
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 11:15:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15556
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 11:15:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15465;
	Tue, 13 Aug 2002 11:15:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15432
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 11:15:56 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15459
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 11:14:37 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g7DFFn924797;
	Tue, 13 Aug 2002 17:15:49 +0200
Message-ID: <3D591DEC.1080609@net4u.ch>
Date: Tue, 13 Aug 2002 07:55:40 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Naiming Shen <naiming@redback.com>
CC: Dave Katz <dkatz@juniper.net>, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ...
References: <20020813060201.3E610CAB6B@prattle.redback.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Naiming Shen wrote:

>Tony,
>
>agree with most of your comments.
>
the further we apart, the more we agree ;-)

>
> ] 
> ] >This would seem to reduce the proposal to a form of link quality detection,
> ] >which really ought not be part of ISIS.
> ] >
> ] yes, that's the main danger here, we start to build link-monitor things 
> ] into a routing protocol
> ] and that has a high potential to embarass us later ...
>
>at least the "iih sending time slip" data has nothing to do with
>"link-monitor" things:-) even if this did reduce to a "link-monitoring"
>mechanism, this is for our protocol use as long as there is no such
>things exist to use, so i don't feel there is something to be embarassed.
>
It is 'kind' of a link-monitoring mechanism and since this groups knows 
close to zilch about it
(or rather, even if we know anything about link monitoring, it's not on 
_this_ charter ;-) so we may
do lots of amateurish mistakes that will cost us face later. Anyway, 
that's just a marginal political angle,
if it is agreed by customers and major vendors
upon as thing to worth pursuit in this group, we hijack some of the 
necessary talent
to review and nurse it into shape ....

So again, still undecided and waiting for more opinions ...

    thanks

    -- tony




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 16:01:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16356
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 16:01:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01033;
	Tue, 13 Aug 2002 15:59:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01007
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 15:59:54 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16134
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 15:58:33 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57C0C@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Noguchi Kay'" <kay@ipinfusion.com>, isis-wg@ietf.org
Subject: RE: [Isis-wg] isisISAdjAreaAddrTable IS-IS MIB, isisISAdjAreaAddr
	ess for index?
Date: Tue, 13 Aug 2002 15:59:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

 
> I encountered one question regarding isisISAdjAreaAddrEntry 
> index in the draft-ietf-isis-wg-mib-08.txt.
> 
> Draft says this entry has five indexes as shown below but I 
> think we don't have to have isisISAdjAreaAddress as index.  
> 
> Can we omit this isisISAdjAreaAddress from indexes for 
> isisISAdjAreaAddrEntry?
> 
>      isisISAdjAreaAddrEntry OBJECT-TYPE
>          SYNTAX IsisISAdjAreaAddrEntry
>          MAX-ACCESS not-accessible
>          STATUS current
>          DESCRIPTION
>              "Each entry contains one Area Address reported by a
>              neighboring Intermediate System in its IIH PDUs."
>          INDEX { isisSysInstance,
>                  isisCircIndex,
>                  isisISAdjIndex,
>                  isisISAdjAreaAddrIndex,
>                  isisISAdjAreaAddress }
>      ::= { isisISAdjAreaAddrTable 1 }
> 
> Thanks in advance,
> 
> 								kay

Kay -
	You are right.  I had added the isisISAdjAreaAddrIndex so that 
I could drop the use of isisISAdjAreaAddress as an index, after
many complaints.  
	I have removed isisISAdjAreaAddress as an index from the table.  

- jeff parker

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 16:03:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16497
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 16:03:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01166;
	Tue, 13 Aug 2002 16:00:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01132
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 16:00:09 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16148
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 15:58:49 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57C0D@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Noguchi Kay'" <kay@ipinfusion.com>, isis-wg@ietf.org
Subject: RE: [Isis-wg] isisISAdjProtSuppEntry index
Date: Tue, 13 Aug 2002 15:59:22 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

 
> I have another question, this time is isisISAdjProtSuppEntry.
> Current draft says we have four indexes shown below but I 
> think this is not good enough. We should have isisISAdjIndex 
> like other isisISAdj*Entries and we doesn't need 
> isisISAdjProtSuppProtocol as index.
> 
>      isisISAdjProtSuppEntry OBJECT-TYPE
>          SYNTAX IsisISAdjProtSuppEntry
>          MAX-ACCESS not-accessible
>          STATUS current
>          DESCRIPTION
>              "Each entry contains one protocol supported by a
>              neighboring Intermediate System as reported in its IIH
>              PDUs."
>          INDEX {  isisSysInstance,
>              isisCircIndex,
>              isisISAdjProtSuppIndex,
>              isisISAdjProtSuppProtocol }
>      ::= { isisISAdjProtSuppTable 1 }
> 
> So we should change isisISAdjProtSuppEntry's index like below.
> Can we?
> 
>      isisISAdjProtSuppEntry OBJECT-TYPE
>          SYNTAX IsisISAdjProtSuppEntry
>          MAX-ACCESS not-accessible
>          STATUS current
>          DESCRIPTION
>              "Each entry contains one protocol supported by a
>              neighboring Intermediate System as reported in its IIH
>              PDUs."
>          INDEX {  isisSysInstance,
>                   isisCircIndex,
>                   isisISAdjIndex,
>                   isisISAdjProtSuppIndex }
>      ::= { isisISAdjProtSuppTable 1 }
> 
> Thank you,
> 
> 								kay

Kay -

I have checked my current copy of the MIB.  Someone else
has suggested the change to to use the ISAdjIndex.  The
current table is shown below.

Help me understand how a ProtSuppIndex will be an
improvement over simply listing the protocols 
supported.  The protocols are one byte values,
and should be easy to walk such a table.  

- jeff parker

     isisISAdjProtSuppEntry OBJECT-TYPE
        SYNTAX IsisISAdjProtSuppEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Each entry contains one protocol supported by a
             neighboring Intermediate System as reported in its IIH
             PDUs."
        INDEX {  isisSysInstance,
            isisCircIndex,
            isisISAdjIndex,
            isisISAdjProtSuppProtocol }
    ::= { isisISAdjProtSuppTable 1 }

    IsisISAdjProtSuppEntry ::=
        SEQUENCE {
            isisISAdjProtSuppProtocol
                SupportedProtocol
        }

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 16:27:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17690
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 16:27:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05913;
	Tue, 13 Aug 2002 16:27:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05881
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 16:27:10 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17556
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 16:25:49 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7DKQZm73086;
	Tue, 13 Aug 2002 13:26:35 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7DKQZ463215;
	Tue, 13 Aug 2002 13:26:35 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Tue, 13 Aug 2002 13:26:35 -0700 (PDT)
Message-Id: <200208132026.g7DKQZ463215@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: prz@net4u.ch
CC: naiming@redback.com, isis-wg@ietf.org
In-reply-to: <3D58789F.3030907@net4u.ch> (message from Tony Przygienda on Mon,
	12 Aug 2002 20:10:23 -0700)
Subject: Re: [Isis-wg] Meeting minutes ...
References: <20020812234103.395A039B5B3@prattle.redback.com> <200208130118.g7D1ITX60701@cirrus.juniper.net> <3D58789F.3030907@net4u.ch>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

   hmmm, I think your assertion that hellos will not languish in queues is 
   a little bit of a jump.
   Even in an excellent implementation with a nice load-shedding, once you 
   get to the point
   where you cannot minimally process things real-time (maybe your box
   is doing plenty high priority other stuff and you have so many 
   adjacencies that just
   sorting things in and out into proper queues/processes/tasks takes 
   serious time and maybe
   the whole thing is only transitory), all kind of trade-offs
   exist as to drop vs. queue. Nothing surprising there, store-and-forward 
   vs. hot-potato
   vs. preventive drop strategies, every overprovisioned system in control 
   theory is in the
   same space. So things may languish in queues some and if they share 
   queues, those
   queues can grow long. But maybe I completely misunderstood what you are 
   trying to say.

Mostly I was trying to make a case that measuring interarrival time was
sufficient to guess at packet drop counts, assuming that something useful
can be done with this information (which I don't think is true.)  It's
also the case that significantly late deliveries of Hello packets will
break the protocol, so if the system is architected in such a way that
Hellos can be delivered very late, then it is arguably seriously broken.

   >
   >
   >I don't see how this is useful in practice for tuning the hello
   >protocol in any case.  Adjacency drops are deeply anomalous events,
   >often with very steep onset, and the anomalies are not predictable.
   >
   Hmm, I tend to slightly disagree here. If you take just ISIS in a box 
   and you load it
   up smoothly with more and more adjacencies, properly designed 
   load-shedding will
   start to show a nice increase in drop rate from a certain point in time 
   that will be
   probabilistically measurable and then such a scheme would allow you to 
   get the
   probability numbers you need.  However, for an implementation that sheds 
   based on
   'over X% CPU load, I drop ALL the hello packets' it will be useless. 
   Guess my point is,
   without having a 'model' of an implementation we can agree on, we may be 
   writing
   lots of e-mails without ever communicating.

This is at the heart of my argument, which is that you can't really model
implementations, and they tend not to do anything smoothly.  If you add
adjacencies until you cannot keep up with the hello load, this tells
you nothing at all about how stable the system will be when something
really bad happens.  I guess my claim is that measuring hello drops
really doesn't tell you anything terribly useful operationally.

   >
   >Implementations in which adjacency stability depends on CPU load or
   >latency are doomed to collapse catastrophically sooner or later, and
   >trying to be clever about tuning will likely only move you closer to
   >the cliff.  
   >
   yes, at a ceratin point in time _any_ implementation that takes an 
   arbitrary amount of
   adjacencies will collapse, be it based on CPU overload or by capping off 
   the amount
   of adjacencies to protect from CPU overload (but even then it will 
   collapse, it's a well-known
   control theory thing, if you need to classify your input, your system 
   will melt at ceratin
   point in time).   By collapse I mean ' it does not serve all adjacencies 
   anymore '.

   >Those which are independent won't measure much of anything
   >interesting, since they should only start to reliably drop hellos only
   >when the hello processing dominates the CPU, which is an untenable
   >regime in which to operate.
   >
   yes, we're in sync here but this is a softer solution space than you 
   make it sound.
   An implementation could say 'I do hellos and start to drop them from a 
   certain queue
   length on and I always serve some flooding at lower priority. Once I see 
   unatainable amount of
   drop statistically per adjacency, I start to be lazier and lazier with 
   flooding'. Yes, it's playing the edge
   I do _not_ think is worth playing but then this number could be usefull. 
    In principle I guess
   I agree with you that optimizing the implementation to the point where 
   you start to
   walk the chaos boundary *(which this thing ultimately is a tool for) is 
   not worth in
   this kind of protocols.

I think we're in nonviolent semiagreement here.  My fundamental beef
is this--Hellos should not be a significant load relative to the
overall capacity of the system, because if they are, you are very
likely to collapse when something important happens (like somebody
advertises full routing into their IGP, one of my favorite pissing
match tests, or even something as simple as a router crashing in a
heavily meshed network.)  When things really start to crank, the
(constant) hello traffic will be in the noise relative to the flooding
traffic, and as such is close to useless in being used as a
measurement tool for network size and tuning.  Measuring Hello loss
only tells you about the capacity of the routing system when it is
quiescent, which is both uninteresting and misleading.  Routing protocols
are kind of like aviation--hours of boredom punctuated by moments of
sheer terror.  ;-)


   >This would seem to reduce the proposal to a form of link quality detection,
   >which really ought not be part of ISIS.
   >
   yes, that's the main danger here, we start to build link-monitor things 
   into a routing protocol
   and that has a high potential to embarass us later ...

It's just the wrong place for such functionality.

   I guess I'm neither for nor vs. this thing but I find the discussion 
   somehow intriguing.

It would be much more interesting to look at link-state retransmission
rates under battle conditions instead if you really want to get a feel
for capacity.

To restate my original argument (now that it's daytime, maybe I'll be
more coherent), the most important task for a router is to send and
receive IGP hellos.  More important than link-state data, more
important than user packets, more important than management.  If a
system is architected in this way, then Hellos will basically never be
dropped unless you're operating the box in a regime that simply will
not work (it has no cycles left to do anything like routing table
calculations.)  For such systems, measuring the drops don't tell you
anything.  If a system is not architected in this way, then the intent
of the proposal seems to be, as you point out, to try to operate
closer to the edge than is currently the case, but the edge has a way
of suddenly running past you, and then your network looks like the
coyote in a Roadrunner cartoon.

Rather than trying to avoid the cliff, design the system so that it
doesn't have a cliff, and you get to work on a whole different set
of issues instead (hopefully less catastrophic ones.)

--Dave


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 16:32:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18028
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 16:32:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06706;
	Tue, 13 Aug 2002 16:29:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06653
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 16:29:03 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17679
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 16:27:43 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57C11@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
Date: Tue, 13 Aug 2002 16:28:26 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Isis-wg] Resubmission of ISIS MIB
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Enough changes have gone into the MIB that it is time for a fresh 
revision.  My change list from the document is included below.    

Note the change in spacing, long overdue to give uniform formatting
throughout.  If you need to check diffs by hand, you will need to
use the -w option to diff to filter out the noise from these changes.  

The biggest substantive change is to reorder counters.  This should
make it simpler to perform periodic scans of the counters.  

- jeff parker


-- Changes in version 09
--      Remove isisCircMCAddr.  Token Ring now uses proper MCast addresses
--      Fixed order of indicies in isisIPRATable
--      Added WideMetric and FullMetric to compliment DefaultMetric
--      Added these to several objects
--      Dropped AdminState from isisSummAddrTable. Only L1 to L2 makes sense
--      Added isisRedistributeAddrTable to manage Domain Wide Prefixes
--      Replace isisISAdjProtSuppIndex with isisISAdjIndex
--      Moving counters to a new subtree.  Have three types
--                { system, level }                     - System wide
--                { system, circuit, level }            - per circuit
specific
--                { system, circuit, level, direction } - PDU counts
--      Removed MaxAreaCheck.  All implementations should check
--      Moved isisSysExistState
--      Replaced isisCircLevelLANDesISChanges with isisCircLANDesISChanges
--      Restored definition of ManualOrAutomatic behavior
--      More objects include the ManualOrAutomatic behavior
--      Remove definition of OperationalState behaviour
--      Fixed "may set the state to 'waiting'" rather than wait
--      Changed syntax of isisCircSmallHellos from AdminState to TruthValue
--      AdminState values swapped to line up with RFC 2863
--      CircuitID is always 7 bytes
--      Formating changes to regularize spacing.
--      Replaced isisCircPtToPtCircID with isisCircLevelCircID
--      Removed isisISAdjAreaAddress as an index to isisISAdjAreaAddrTable.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 17:20:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20988
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 17:20:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11733;
	Tue, 13 Aug 2002 17:02:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11691
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 17:02:18 -0400 (EDT)
Received: from mailbox.office.aol.com (x98A3A121.pix.aol.com [152.163.161.33])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19233
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 17:00:57 -0400 (EDT)
Received: from pcsn630877 ([10.0.198.45])
	by mailbox.office.aol.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id RAA16609;
	Tue, 13 Aug 2002 17:01:38 -0400 (EDT)
Reply-To: <micklesc@aol.net>
From: "Cleve Mickles" <micklesc@aol.net>
To: "Naiming Shen" <naiming@redback.com>, <prz@net4u.ch>
Cc: <isis-wg@ietf.org>, "Dave Katz" <dkatz@juniper.net>
Subject: RE: [Isis-wg] Meeting minutes ...
Date: Tue, 13 Aug 2002 17:01:32 -0400
Message-ID: <NFBBKCMPAMBLMHAHHIMBAENODLAA.micklesc@aol.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3D591DEC.1080609@net4u.ch>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit


This would be a good troubleshooting tool for large ISIS networks
and specifically for point-2-multipoint networks as I( and Naiming)
worked on in our previous lives.

If folks are (or start) using more GbE or 10GbE to interconnect routers
then tracking the hello sequence numbers adds value.  As Route Processors
have increased in CPU power it is not clear how much of a problem dropped
or out of sequence hellos are today.  If it doesn't add much overhead, then
having the option to monitor IIH sequence numbers would be another
tool to ISPs can use to identify which side of an adjacency is having
problems.

Cleve...

> -----Original Message-----
> From: isis-wg-admin@ietf.org [mailto:isis-wg-admin@ietf.org]On Behalf Of
> Tony Przygienda
> Sent: Tuesday, August 13, 2002 10:56 AM
> To: Naiming Shen
> Cc: Dave Katz; isis-wg@ietf.org
> Subject: Re: [Isis-wg] Meeting minutes ...
>
>
> Naiming Shen wrote:
>
> >Tony,
> >
> >agree with most of your comments.
> >
> the further we apart, the more we agree ;-)
>
> >
> > ]
> > ] >This would seem to reduce the proposal to a form of link
> quality detection,
> > ] >which really ought not be part of ISIS.
> > ] >
> > ] yes, that's the main danger here, we start to build
> link-monitor things
> > ] into a routing protocol
> > ] and that has a high potential to embarass us later ...
> >
> >at least the "iih sending time slip" data has nothing to do with
> >"link-monitor" things:-) even if this did reduce to a "link-monitoring"
> >mechanism, this is for our protocol use as long as there is no such
> >things exist to use, so i don't feel there is something to be embarassed.
> >
> It is 'kind' of a link-monitoring mechanism and since this groups knows
> close to zilch about it
> (or rather, even if we know anything about link monitoring, it's not on
> _this_ charter ;-) so we may
> do lots of amateurish mistakes that will cost us face later. Anyway,
> that's just a marginal political angle,
> if it is agreed by customers and major vendors
> upon as thing to worth pursuit in this group, we hijack some of the
> necessary talent
> to review and nurse it into shape ....
>
> So again, still undecided and waiting for more opinions ...
>
>     thanks
>
>     -- tony
>
>
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www1.ietf.org/mailman/listinfo/isis-wg
>

Cleve Mickles
Network Architecture
America Online, Network Operations



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 17:21:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21067
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 17:21:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13346;
	Tue, 13 Aug 2002 17:20:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13317
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 17:20:31 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20908
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 17:19:10 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7DLJmm77134;
	Tue, 13 Aug 2002 14:19:48 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7DLJmt63341;
	Tue, 13 Aug 2002 14:19:48 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Tue, 13 Aug 2002 14:19:48 -0700 (PDT)
Message-Id: <200208132119.g7DLJmt63341@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: naiming@redback.com
CC: prz@net4u.ch, isis-wg@ietf.org
In-reply-to: <20020813053300.EF5E718D3E5@prattle.redback.com> (message from
	Naiming Shen on Mon, 12 Aug 2002 22:33:00 -0700)
Subject: Re: [Isis-wg] Meeting minutes ...
References:  <20020813053300.EF5E718D3E5@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

    - some ISPs used to set holddown time rather long, say 1.5 minutes.
      so the questions is with so much changes since the people invented
      this 1.5 minutes number, is it safe to lower it? lower to what?
      with this seq# scheme, it at least give you some history when a
      user start to change the numbers. is there packet loss during the
      busy hours, network churn times, is neighbor's IIH usually sent
      on time, offset by how much? If one has those numbers, they can
      take the conservative approach by setting it to a very safe value.

This is because we were, um, naive about such things when the code was
written that required such extreme hold times.  The real problem was a
combination of a lack of priority queueing (at the hardware level) for
ISIS packets, lousy prioritization of IIHs versus other ISIS packets
within the protocol implementation, and hello transmission latency
that was affected by CPU load and was essentially unbounded.  Systems
for which these problems are still true are always going to collapse
under load, and IIH loss measurement is not going to avoid this,
because the collapse conditions are (hopefully) very rare and very
anomalous, and as such you are not going to be able to measure or
model them meaningfully.

    - normally, as you mentioned, if the IIH packets are handled properly,
      the loss, delay probability is not high. but in some cases when
      there is large number of adjs or very fast hellos, how much buffer
      space is enough? I'm not proposing to run with huge number of adjs
      or tune down the iih hold time to extreme low, but those things does
      impact the protocol implementations.

If you have *any* loss under steady state conditions due to the sheer
number of Hello packets, then you're operating too close to the edge.
It shouldn't be a buffering issue unless your IIH processing latency
is seriously chunky (at which point the buffering requirements are not
predictable anyhow.)

    - when vendors/customers do the IGP scalability testing, what do they
      do if the adjacencies start to drop? just stop? that's fine. but there
      maybe some silly mistakes in the code caused this. If you can have
      more info on what's going on, you can get rid of next round of
      bottlenecks to push those numbers further. those data helps to
      implement protocols better.

This is much better addressed through instrumentation of the implementation.

    ]  Adjacency drops are deeply anomalous events,
    ] often with very steep onset, and the anomalies are not predictable.
    ] Implementations in which adjacency stability depends on CPU load or
    ] latency are doomed to collapse catastrophically sooner or later, and
    ] trying to be clever about tuning will likely only move you closer to
    ] the cliff. 

   what your saying is mostly true. but seq# miss, sending time slip
   may not necessary mean adjacency drops. If you have high number
   of multipliers, maybe it's perfectly ok to have those misses. But
   it is also nice to know if there is miss or not, this will be the
   first indication to the users/testers of something is stretched too far.

High multipliers should never be necessary unless the system has serious
queueing problems;  in fact, most of the time they work against you if
you are taking any significant Hello processing load.

    ] Those which are independent won't measure much of anything
    ] interesting, since they should only start to reliably drop hellos only
    ] when the hello processing dominates the CPU, which is an untenable
    ] regime in which to operate.

   I'm not suggest people should detect the boundary, then just set the
   settings on those boundaries. I'm saying its nice to know those boudaries,
   also users can intelligently use those data to set their comfortable
   numbers.

My claim is that the "boundary" that you are really trying to
determine is "how hard can I push the network without it collapsing"
and that such a boundary cannot be determined because it is not fixed.
Furthermore, there are lots of other mechanisms already available for
characterizing performance under load that are independent of the
protocol spec.

    ] 
    ] This would seem to reduce the proposal to a form of link quality detection,
    ] which really ought not be part of ISIS.

   I don't think this seq# scheme is just here for detect line noise or
   link congestions. But if we do believe that vendors always implement
   properly, or we will only handle some "reasonable" numbers, then I
   do agree that there is no place for this scheme.

There are a couple of issues intermixed here, I think.

One issue is to try to track dropped IIHs.  This can be done by other
means (pulling xmit stats from one side and rcv stats on the other,
for example, or measuring the baseline arrival rate and then seeing
how it is affected by load) albeit not at the level of granularity
that this scheme would provide.  I would make the brash and not
particularly supportable claim that the high granularity comes with
little benefit, but that's my opinion.

Another issue is whether tracking dropped IIHs to a high granularity
is operationally useful.  I just don't see this, and none of the
examples given seem (to me) to be compelling.  Further, it will give
customers a false impression that it actually *is* useful, and
somebody will doubtlessly twist knobs in unreasonable ways, see that
there is no drop, and then get very upset when their network has
problems.


It's a simple enough proposal, and as such I really don't care that
much about it (the additional complexity added is almost
unmeasurable), but without a really compelling argument of its
usefulness it does not seem a good candidate for expending time and
trees (or oxide particles) to get it through standardization.

I'll happily switch sides if somebody can show me something compelling
and concrete that this will gain us; my intuition is not known to be
infallible.

--Dave

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 17:39:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21923
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 17:39:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15626;
	Tue, 13 Aug 2002 17:32:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15576
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 17:32:23 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21601
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 17:31:02 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7DLVhm78085;
	Tue, 13 Aug 2002 14:31:43 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7DLVhA63383;
	Tue, 13 Aug 2002 14:31:43 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Tue, 13 Aug 2002 14:31:43 -0700 (PDT)
Message-Id: <200208132131.g7DLVhA63383@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: micklesc@aol.net
CC: naiming@redback.com, prz@net4u.ch, isis-wg@ietf.org
In-reply-to: <NFBBKCMPAMBLMHAHHIMBAENODLAA.micklesc@aol.net>
Subject: Re: [Isis-wg] Meeting minutes ...
References:  <NFBBKCMPAMBLMHAHHIMBAENODLAA.micklesc@aol.net>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

   This would be a good troubleshooting tool for large ISIS networks
   and specifically for point-2-multipoint networks as I( and Naiming)
   worked on in our previous lives.

   If folks are (or start) using more GbE or 10GbE to interconnect routers
   then tracking the hello sequence numbers adds value.  As Route Processors
   have increased in CPU power it is not clear how much of a problem dropped
   or out of sequence hellos are today.  If it doesn't add much overhead, then
   having the option to monitor IIH sequence numbers would be another
   tool to ISPs can use to identify which side of an adjacency is having
   problems.

If you can get a statistical approximation of the drop rate per
neighbor without changing the protocol, would that suffice?
Presumably, knowing that one or two hellos disappeared into the void
is not interesting, but 5 or 10 percent would be.  This should be easy
to do without torquing the protocol spec.


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 17:55:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22704
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 17:55:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17832;
	Tue, 13 Aug 2002 17:54:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17805
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 17:54:30 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22556
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 17:53:08 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57C16@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
Subject: [Isis-wg]  Hello PDU sequence numbers
Date: Tue, 13 Aug 2002 17:53:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Subject changed to more relevant name.  


> >   This would be a good troubleshooting tool for large ISIS networks
> >   and specifically for point-2-multipoint networks as I( and Naiming)
> >   worked on in our previous lives.
>
> If you can get a statistical approximation of the drop rate per
> neighbor without changing the protocol, would that suffice?
> Presumably, knowing that one or two hellos disappeared into the void
> is not interesting, but 5 or 10 percent would be.  This should be easy
> to do without torquing the protocol spec.
> 
> [Dave Katz]
 
The PDU counters in the MIB today provide what Dave is 
describing.  It would be easy to compare the counts from 
the two sides of a connection.  The 09 version of the table 
follows.

This level of detail is much less fine that the sequence counters 
permits.  But how could we convey such detail to the outside world? 
I suppose we could send a sequence like the following, but this
reminds me of an IQ test rather than a measurement suitable for 
recording.  

	{1, 4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20 ...}  

- jeff parker

    isisPacketCounterTable OBJECT-TYPE
        SYNTAX SEQUENCE OF IsisPacketCounterEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Information about IS-IS protocol traffic at one level
             on one circuit in one direction"
    ::= { isisCounters 3 }

    isisPacketCounterEntry OBJECT-TYPE
        SYNTAX IsisPacketCounterEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Information about IS-IS protocol traffic at one level
             on one circuit in one direction"
        INDEX { isisSysInstance,
                isisCircIndex,
                isisPacketCountLevel,
                isisPacketCountDirection }
    ::= { isisPacketCounterTable 1 }

    IsisPacketCounterEntry ::=
        SEQUENCE {
            isisPacketCountLevel
                INTEGER,
            isisPacketCountDirection
                INTEGER,
            isisPacketCountHello
                Counter32,
            isisPacketCountLSP
                Counter32,
            isisPacketCountCSNP
                Counter32,
            isisPacketCountPSNP
                Counter32
    }

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 18:14:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23282
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 18:14:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19665;
	Tue, 13 Aug 2002 18:08:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19618
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 18:08:19 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23093
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 18:06:57 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g7DM8B926317;
	Wed, 14 Aug 2002 00:08:11 +0200
Message-ID: <3D597E8E.3090807@net4u.ch>
Date: Tue, 13 Aug 2002 14:47:58 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Katz <dkatz@juniper.net>
CC: naiming@redback.com, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ...
References: <20020812234103.395A039B5B3@prattle.redback.com> <200208130118.g7D1ITX60701@cirrus.juniper.net> <3D58789F.3030907@net4u.ch> <200208132026.g7DKQZ463215@cirrus.juniper.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Dave Katz wrote:

>
>
>   >
>   >
>   >I don't see how this is useful in practice for tuning the hello
>   >protocol in any case.  Adjacency drops are deeply anomalous events,
>   >often with very steep onset, and the anomalies are not predictable.
>   >
>   Hmm, I tend to slightly disagree here. If you take just ISIS in a box 
>   and you load it
>   up smoothly with more and more adjacencies, properly designed 
>   load-shedding will
>   start to show a nice increase in drop rate from a certain point in time 
>   that will be
>   probabilistically measurable and then such a scheme would allow you to 
>   get the
>   probability numbers you need.  However, for an implementation that sheds 
>   based on
>   'over X% CPU load, I drop ALL the hello packets' it will be useless. 
>   Guess my point is,
>   without having a 'model' of an implementation we can agree on, we may be 
>   writing
>   lots of e-mails without ever communicating.
>
>This is at the heart of my argument, which is that you can't really model
>implementations, and they tend not to do anything smoothly.  If you add
>adjacencies until you cannot keep up with the hello load, this tells
>you nothing at all about how stable the system will be when something
>really bad happens.  I guess my claim is that measuring hello drops
>really doesn't tell you anything terribly useful operationally.
>
Practically speaking (many more things than just ISIS on the box, data 
on same link as control)
you are of course right.  So far the only good link-state models I saw 
were limiting themselves to only
a single protocol on the box and albeit neat, the output of this kind of 
work was of academic
interest only (so far).

>I think we're in nonviolent semiagreement here.  My fundamental beef
>is this--Hellos should not be a significant load relative to the
>overall capacity of the system, because if they are, you are very
>likely to collapse when something important happens (like somebody
>advertises full routing into their IGP, one of my favorite pissing
>match tests, or even something as simple as a router crashing in a
>heavily meshed network.)  When things really start to crank, the
>(constant) hello traffic will be in the noise relative to the flooding
>traffic, and as such is close to useless in being used as a
>measurement tool for network size and tuning.  Measuring Hello loss
>only tells you about the capacity of the routing system when it is
>quiescent, which is both uninteresting and misleading.  
>

>Routing protocols
>are kind of like aviation--hours of boredom punctuated by moments of
>sheer terror.  ;-)
>
Only if you deploy them, if you just hack them and other people deploy 
them for you, it's
like building planes, most of the time you have fun ;-)

>
>
>
>   >This would seem to reduce the proposal to a form of link quality detection,
>   >which really ought not be part of ISIS.
>   >
>   yes, that's the main danger here, we start to build link-monitor things 
>   into a routing protocol
>   and that has a high potential to embarass us later ...
>
>It's just the wrong place for such functionality.
>
>   I guess I'm neither for nor vs. this thing but I find the discussion 
>   somehow intriguing.
>
>It would be much more interesting to look at link-state retransmission
>rates under battle conditions instead if you really want to get a feel
>for capacity.
>
>To restate my original argument (now that it's daytime, maybe I'll be
>more coherent), the most important task for a router is to send and
>receive IGP hellos.  More important than link-state data, more
>important than user packets, more important than management.  If a
>system is architected in this way, then Hellos will basically never be
>dropped unless you're operating the box in a regime that simply will
>not work (it has no cycles left to do anything like routing table
>calculations.)  For such systems, measuring the drops don't tell you
>anything.  If a system is not architected in this way, then the intent
>of the proposal seems to be, as you point out, to try to operate
>closer to the edge than is currently the case, but the edge has a way
>of suddenly running past you, and then your network looks like the
>coyote in a Roadrunner cartoon.
>
>Rather than trying to avoid the cliff, design the system so that it
>doesn't have a cliff, and you get to work on a whole different set
>of issues instead (hopefully less catastrophic ones.)
>
I slowly start to see which corner of the world you are coming from. 
Yes, we are in a semi-agreement,
I am a little bit more tempered than you are in terms of conclusions you 
drew through the years (going from
no-priotization to all hellos always first) since from control theory I 
took with me that you should
build priotized systems but that you shall also avoid starvation of 
lower priority packets and you should start to
shed load way before you going into overload conditions. Given those 
kind of designs, hello
losses can signal upcoming overload way before you start to walk the 
chaos boundary (which as
you say strikes on unpredictably and in places one often doesn't expect) 
and
tell you possibly usefull things.

I deduct we are in full agreement that it is hard to actually tell 
'WHAT' this number is telling you and
whether the reasons Naiming/Cleve brings up makes it worthwile to twist 
the protocol in this direction.
And what troubles me more and more: is it even an 'interoperability' 
problem and therefore in the scope
of this group?

Speaking of which: what would be your alternative to measure the point 
at which you would decide
that the protocol 'melted down' and one should start to back-off timers, 
increase buffers or not run that
many adjacencies?


    -- tony








_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 18:19:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23431
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 18:19:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20351;
	Tue, 13 Aug 2002 18:18:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20325
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 18:18:33 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23365
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 18:17:11 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 9775939B5B9; Tue, 13 Aug 2002 15:18:30 -0700 (PDT)
To: Jeff Parker <jparker@axiowave.com>
Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Hello PDU sequence numbers 
In-reply-to: Mail from Jeff Parker <jparker@axiowave.com> 
 dated Tue, 13 Aug 2002 17:53:50 EDT
 <EB5FFC72F183D411B38200062957342901E57C16@r2d2.axiowave.com> 
Date: Tue, 13 Aug 2002 15:18:30 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020813221830.9775939B5B9@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


Jeff,

 ] Subject changed to more relevant name.  
 ] 

thanks. if i follow the below logic correctly, can i say that MIB is
not needed, since telnet has offered the exact information ?-(

Cheers.

 ] 
 ] > >   This would be a good troubleshooting tool for large ISIS networks
 ] > >   and specifically for point-2-multipoint networks as I( and Naiming)
 ] > >   worked on in our previous lives.
 ] >
 ] > If you can get a statistical approximation of the drop rate per
 ] > neighbor without changing the protocol, would that suffice?
 ] > Presumably, knowing that one or two hellos disappeared into the void
 ] > is not interesting, but 5 or 10 percent would be.  This should be easy
 ] > to do without torquing the protocol spec.
 ] > 
 ] > [Dave Katz]
 ]  
 ] The PDU counters in the MIB today provide what Dave is 
 ] describing.  It would be easy to compare the counts from 
 ] the two sides of a connection.  The 09 version of the table 
 ] follows.
 ] 
 ] This level of detail is much less fine that the sequence counters 
 ] permits.  But how could we convey such detail to the outside world? 
 ] I suppose we could send a sequence like the following, but this
 ] reminds me of an IQ test rather than a measurement suitable for 
 ] recording.  
 ] 
 ] 	{1, 4, 6, 8, 9, 10, 12, 14, 15, 16, 18, 20 ...}  
 ] 
 ] - jeff parker
 ] 
 ]     isisPacketCounterTable OBJECT-TYPE
 ]         SYNTAX SEQUENCE OF IsisPacketCounterEntry
 ]         MAX-ACCESS not-accessible
 ]         STATUS current
 ]         DESCRIPTION
 ]             "Information about IS-IS protocol traffic at one level
 ]              on one circuit in one direction"
 ]     ::= { isisCounters 3 }
 ] 
 ]     isisPacketCounterEntry OBJECT-TYPE
 ]         SYNTAX IsisPacketCounterEntry
 ]         MAX-ACCESS not-accessible
 ]         STATUS current
 ]         DESCRIPTION
 ]             "Information about IS-IS protocol traffic at one level
 ]              on one circuit in one direction"
 ]         INDEX { isisSysInstance,
 ]                 isisCircIndex,
 ]                 isisPacketCountLevel,
 ]                 isisPacketCountDirection }
 ]     ::= { isisPacketCounterTable 1 }
 ] 
 ]     IsisPacketCounterEntry ::=
 ]         SEQUENCE {
 ]             isisPacketCountLevel
 ]                 INTEGER,
 ]             isisPacketCountDirection
 ]                 INTEGER,
 ]             isisPacketCountHello
 ]                 Counter32,
 ]             isisPacketCountLSP
 ]                 Counter32,
 ]             isisPacketCountCSNP
 ]                 Counter32,
 ]             isisPacketCountPSNP
 ]                 Counter32
 ]     }
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] Isis-wg@ietf.org
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 18:34:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23990
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 18:34:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22052;
	Tue, 13 Aug 2002 18:31:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22017
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 18:31:29 -0400 (EDT)
Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23818
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 18:30:07 -0400 (EDT)
Message-ID: <EB5FFC72F183D411B38200062957342901E57C1A@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Naiming Shen'" <naiming@redback.com>
Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
Subject: RE: [Isis-wg] Hello PDU sequence numbers 
Date: Tue, 13 Aug 2002 18:30:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

> If I follow the below logic correctly, can I say that MIB is
> not needed, since telnet has offered the exact information ?-(
> 
> Cheers.

Naiming -

	My point was simply that there is a standard way to get 
the raw counts today.  If there was an IETF standard for the 
IS-IS CLI, telnet would provide an alternative.

- jeff parker

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Aug 13 18:46:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24442
	for <isis-archive@odin.ietf.org>; Tue, 13 Aug 2002 18:46:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23053;
	Tue, 13 Aug 2002 18:43:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23021
	for <isis-wg@optimus.ietf.org>; Tue, 13 Aug 2002 18:43:18 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24284
	for <isis-wg@ietf.org>; Tue, 13 Aug 2002 18:41:56 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 948C8CAB66; Tue, 13 Aug 2002 15:43:15 -0700 (PDT)
To: Dave Katz <dkatz@juniper.net>
Cc: prz@net4u.ch, isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ... 
In-reply-to: Mail from Dave Katz <dkatz@juniper.net> 
 dated Tue, 13 Aug 2002 14:19:48 PDT
 <200208132119.g7DLJmt63341@cirrus.juniper.net> 
Date: Tue, 13 Aug 2002 15:43:15 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020813224315.948C8CAB66@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


Without trying to get into the details...

 ] 
 ] It's a simple enough proposal, and as such I really don't care that
 ] much about it (the additional complexity added is almost
 ] unmeasurable), but without a really compelling argument of its
 ] usefulness it does not seem a good candidate for expending time and
 ] trees (or oxide particles) to get it through standardization.

If asked if there is a really compelling reasons for this
seq# draft, I actually can not think of any myself.

I think everything in this scheme can be achieved somehow by the
existing tools/utility/etc. For example, this seq# can detect
exactly when and how many IIH packets being lost in particular
interface/adjacency. We of course can achieve this by log-on/snmp-get
stats on every router/every link/every minutes to get the same info.
But to have a mechanism to be "event driven" is also nice. Sometimes
we discover problems by surprise. Wouldn't it be nice to find why
one particular adj loss is high than just assume everything must be
fine(assume adj didn't bounce)? but those things may not be
classified as "compelling" though.

thanks.

 ] 
 ] I'll happily switch sides if somebody can show me something compelling
 ] and concrete that this will gain us; my intuition is not known to be
 ] infallible.
 ] 
 ] --Dave

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 07:29:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04702
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 07:29:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22178;
	Wed, 14 Aug 2002 07:28:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22148
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 07:28:37 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04371;
	Wed, 14 Aug 2002 07:27:16 -0400 (EDT)
Message-Id: <200208141127.HAA04371@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: isis-wg@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 14 Aug 2002 07:27:16 -0400
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-admin-tags-00.txt
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

--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		: A Policy Control Mechanism is IS-IS Using 
                          Administrative Tags
	Author(s)	: C. Martin, B. Neal, S. Previdi
	Filename	: draft-ietf-isis-admin-tags-00.txt
	Pages		: 6
	Date		: 13-Aug-02
	
This document describes an extension to the IS-IS protocol to add
operational capabilities that allow for ease of management and
control over IP prefix distribution within an IS-IS domain.  The IS-
IS protocol is specified in [1], with extensions for supporting IPv4
specified in [2] and further enhancements for Traffic Engineering [4]
in [3] and [6].
This document enhances the IS-IS protocol by extending the
information that a Intermediate System (IS) [router] can place in
Link State Protocol Data Units (LSPs) as specified in [2].  This
extension will provide operators with a mechanism to control IP
prefix distribution throughout multi-level IS-IS domains.
Additionally, the information can be placed in LSPs that have TLVs as
yet undefined, if this information is used to convey the same meaning
in these future TLVs as it is used in the currently defined TLVs.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-admin-tags-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-admin-tags-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:	<20020813141545.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-isis-admin-tags-00.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 08:28:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06691
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 08:28:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25305;
	Wed, 14 Aug 2002 08:27:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25274
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 08:27:33 -0400 (EDT)
Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06589
	for <isis-wg@ietf.org>; Wed, 14 Aug 2002 08:26:12 -0400 (EDT)
Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 14 Aug 2002 14:27:31 +0200
Subject: RE: [Isis-wg] Meeting minutes ... 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Wed, 14 Aug 2002 14:27:30 +0200
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <EE012FBB4150A841BBE9352A3EA64CAE0E9177@parmhs2.rd.francetelecom.fr>
Thread-Topic: [Isis-wg] Meeting minutes ... 
Thread-Index: AcJDGvWyqJfV8xB0SnWF9iuOlN/FzwAb66yQ
From: "DUBOIS Nicolas FTRD/DAC/ISS" <nicolas.dubois@rd.francetelecom.com>
To: "Naiming Shen" <naiming@redback.com>, "Dave Katz" <dkatz@juniper.net>
Cc: <prz@net4u.ch>, <isis-wg@ietf.org>
X-OriginalArrivalTime: 14 Aug 2002 12:27:31.0014 (UTC) FILETIME=[F59FDE60:01C2438D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA25275
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 8bit

My understanding is that:

	- Such a mechanism would be useful on unreliable links such as
satellite ones.
	- Such a mechanism would help accounting the time the link was
unreliable and not useful for traffic from the control plane point of
view. You could log the missed sequence number and time somewhere. It
could help detect that one link is too unreliable for control plane
traffic before breaking this control plane traffic and causing
instability in the network.
	- It could be an indicator of control plane health on high
quality link.	
	- Such a mechanism would help on complex broadcast subnets and
parralel links where you do not always understand what is happening. It
could detect duplicate hello packets for example.

For the technical and political details I don't know, even though it
doesn't seem very complicated to implement.

I think it would be useful in our networks, but this doesn't mean we
would use it. There are so many useful refinements in IP that you can't
choose which ones you should use ... 

Best regards,

Nicolas

-----Message d'origine-----
De : Naiming Shen [mailto:naiming@redback.com]
Envoye : mercredi 14 aout 2002 00:43
A : Dave Katz
Cc : prz@net4u.ch; isis-wg@ietf.org
Objet : Re: [Isis-wg] Meeting minutes ... 



Without trying to get into the details...

 ] 
 ] It's a simple enough proposal, and as such I really don't care that
 ] much about it (the additional complexity added is almost
 ] unmeasurable), but without a really compelling argument of its
 ] usefulness it does not seem a good candidate for expending time and
 ] trees (or oxide particles) to get it through standardization.

If asked if there is a really compelling reasons for this
seq# draft, I actually can not think of any myself.

I think everything in this scheme can be achieved somehow by the
existing tools/utility/etc. For example, this seq# can detect
exactly when and how many IIH packets being lost in particular
interface/adjacency. We of course can achieve this by log-on/snmp-get
stats on every router/every link/every minutes to get the same info.
But to have a mechanism to be "event driven" is also nice. Sometimes
we discover problems by surprise. Wouldn't it be nice to find why
one particular adj loss is high than just assume everything must be
fine(assume adj didn't bounce)? but those things may not be
classified as "compelling" though.

thanks.

 ] 
 ] I'll happily switch sides if somebody can show me something
compelling
 ] and concrete that this will gain us; my intuition is not known to be
 ] infallible.
 ] 
 ] --Dave

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 12:42:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16269
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 12:42:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11193;
	Wed, 14 Aug 2002 12:40:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11163
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 12:40:36 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16075
	for <isis-wg@ietf.org>; Wed, 14 Aug 2002 12:39:15 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g7EGeS909947;
	Wed, 14 Aug 2002 18:40:29 +0200
Message-ID: <3D5A833E.1020305@net4u.ch>
Date: Wed, 14 Aug 2002 09:20:14 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: DUBOIS Nicolas FTRD/DAC/ISS <nicolas.dubois@rd.francetelecom.com>
CC: Naiming Shen <naiming@redback.com>, Dave Katz <dkatz@juniper.net>,
        isis-wg@ietf.org
Subject: Re: [Isis-wg] Meeting minutes ...
References: <EE012FBB4150A841BBE9352A3EA64CAE0E9177@parmhs2.rd.francetelecom.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

DUBOIS Nicolas FTRD/DAC/ISS wrote:

>My understanding is that:
>
>	- Such a mechanism would be useful on unreliable links such as
>satellite ones.
>	- Such a mechanism would help accounting the time the link was
>unreliable and not useful for traffic from the control plane point of
>view. You could log the missed sequence number and time somewhere. It
>could help detect that one link is too unreliable for control plane
>traffic before breaking this control plane traffic and causing
>instability in the network.
>	- It could be an indicator of control plane health on high
>quality link.	
>	- Such a mechanism would help on complex broadcast subnets and
>parralel links where you do not always understand what is happening. It
>could detect duplicate hello packets for example.
>
>For the technical and political details I don't know, even though it
>doesn't seem very complicated to implement.
>
technically is very simple to do (and optional anyway)

politically this group has always had the philosophy of airing the 
politics on the list, albeit
sometimes in the background a first round of 'densification' by relevant 
parties was happening
to not let the list run wild ...  At least that's my perception.

so none of the above has an implication of whether it will happen or 
not, the issue is
purely whether there is enough merit to justify doing it.

    -- tony


>
>
>I think it would be useful in our networks, but this doesn't mean we
>would use it. There are so many useful refinements in IP that you can't
>choose which ones you should use ... 
>
>Best regards,
>
>Nicolas
>
>-----Message d'origine-----
>De : Naiming Shen [mailto:naiming@redback.com]
>Envoye : mercredi 14 aout 2002 00:43
>A : Dave Katz
>Cc : prz@net4u.ch; isis-wg@ietf.org
>Objet : Re: [Isis-wg] Meeting minutes ... 
>
>
>
>Without trying to get into the details...
>
> ] 
> ] It's a simple enough proposal, and as such I really don't care that
> ] much about it (the additional complexity added is almost
> ] unmeasurable), but without a really compelling argument of its
> ] usefulness it does not seem a good candidate for expending time and
> ] trees (or oxide particles) to get it through standardization.
>
>If asked if there is a really compelling reasons for this
>seq# draft, I actually can not think of any myself.
>
>I think everything in this scheme can be achieved somehow by the
>existing tools/utility/etc. For example, this seq# can detect
>exactly when and how many IIH packets being lost in particular
>interface/adjacency. We of course can achieve this by log-on/snmp-get
>stats on every router/every link/every minutes to get the same info.
>But to have a mechanism to be "event driven" is also nice. Sometimes
>we discover problems by surprise. Wouldn't it be nice to find why
>one particular adj loss is high than just assume everything must be
>fine(assume adj didn't bounce)? but those things may not be
>classified as "compelling" though.
>
>thanks.
>
> ] 
> ] I'll happily switch sides if somebody can show me something
>compelling
> ] and concrete that this will gain us; my intuition is not known to be
> ] infallible.
> ] 
> ] --Dave
>
>- Naiming
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg
>
>




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 14:46:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20998
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 14:46:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14342;
	Wed, 14 Aug 2002 13:44:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14313
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 13:44:16 -0400 (EDT)
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18749
	for <isis-wg@ietf.org>; Wed, 14 Aug 2002 13:42:57 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59)
	id <QSYHNFJW>; Wed, 14 Aug 2002 13:43:46 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB35015F316A@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'isis-wg@ietf.org'" <isis-wg@ietf.org>
Date: Wed, 14 Aug 2002 13:43:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [Isis-wg] E Djikstra Passes Away
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Some of you may have already heard... For those of you who haven't:

http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html

Regards,
chris

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 23:13:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02595
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 23:13:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15596;
	Wed, 14 Aug 2002 23:12:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15566
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 23:12:14 -0400 (EDT)
Received: from kraak.freeler.nl (xs195-241-224-150.dial.tiscali.nl [195.241.224.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02512
	for <isis-wg@ietf.org>; Wed, 14 Aug 2002 23:10:46 -0400 (EDT)
Received: (from henk@localhost)
	by kraak.freeler.nl (8.11.6/8.11.6) id g7F3CWG02627;
	Thu, 15 Aug 2002 05:12:32 +0200
From: Henk Smit <hhwsmit@freeler.nl>
Message-Id: <200208150312.g7F3CWG02627@kraak.freeler.nl>
Subject: Re: [Isis-wg] Hello PDU sequence numbers
To: dkatz@juniper.net (Dave Katz)
Date: Thu, 15 Aug 2002 05:12:32 +0200 (CEST)
Cc: isis-wg@ietf.org
In-Reply-To: <200208130118.g7D1ITX60701@cirrus.juniper.net> from "Dave Katz" at Aug 12, 2002 06:18:29 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit


Dave wrote:

> This would seem to reduce the proposal to a form of link quality detection,
> which really ought not be part of ISIS.


  Cool ! You must have changed your view on the issue of IGP and
 link quality detection. ;-)

  Can we now get rid of that fugly proposal for IS-IS and jumbo frames
 over GigE ? Or is it an RFC already ? I always have understood that
 the reason for that draft was that UUnet and Juniper thought IIHs
 *had* to be mtu-sized, or else the quality of the ethernet link was
 not guaranteed ? That draft added a lot of extra complexity, and all
 you get back is a little extra "link quality detection".

  So if we don't need "link quality detection" in our IGPs, then I assume
 we don't need jumbo ethernet frames for IS-IS either .....

  :p

     Henk.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Aug 14 23:16:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02705
	for <isis-archive@odin.ietf.org>; Wed, 14 Aug 2002 23:16:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15903;
	Wed, 14 Aug 2002 23:16:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15872
	for <isis-wg@optimus.ietf.org>; Wed, 14 Aug 2002 23:15:58 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02644
	for <isis-wg@ietf.org>; Wed, 14 Aug 2002 23:14:37 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7F3FQm75706;
	Wed, 14 Aug 2002 20:15:26 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7F3FQw67351;
	Wed, 14 Aug 2002 20:15:26 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Wed, 14 Aug 2002 20:15:26 -0700 (PDT)
Message-Id: <200208150315.g7F3FQw67351@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: hhwsmit@zonnet.nl
CC: isis-wg@ietf.org
In-reply-to: <200208150309.g7F39AF02537@kraak.freeler.nl> (message from Henk
	Smit on Thu, 15 Aug 2002 05:09:10 +0200 (CEST))
Subject: Re: [Isis-wg] Hello PDU sequence numbers
References:  <200208150309.g7F39AF02537@kraak.freeler.nl>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Hm, I was always against MTU-sided IIHs, at least as far back as I can
remember, which at my advanced age isn't as long as the IETF archives,
I'm afraid.  My revisionist claim is that IIH padding is solely to
ensure that max-sized LSPs can transit the link successfully.  It makes
a lousy MTU negotiation tool, and the detection of the drops of large
frames is probably only useful on point-to-point links, where you don't
pad after the initial exchange anyhow...

--Dave

   X-JNPR-Received-From: outside
   From: Henk Smit <hhwsmit@zonnet.nl>
   Date: Thu, 15 Aug 2002 05:09:10 +0200 (CEST)
   Cc: isis-wg@ietf.org
   Content-Type: text/plain; charset=us-ascii
   X-OriginalArrivalTime: 15 Aug 2002 03:08:51.0936 (UTC) FILETIME=[151C3600:01C24409]
   X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)


   Dave wrote:

   > This would seem to reduce the proposal to a form of link quality detection,
   > which really ought not be part of ISIS.

     Cool ! You must have changed your view on the issue of IGP and
    link quality detection. ;-)

     Can we now get rid of that fugly proposal for IS-IS and jumbo frames
    over GigE ? Or is it an RFC already ? I always have understood that
    the reason for that draft was that UUnet and Juniper thought IIHs
    *had* to be mtu-sized, or else the quality of the ethernet link was
    not guaranteed ? That draft added a lot of extra complexity, and all
    you get back is a little extra "link quality detection".

     So if we don't need "link quality detection" in our IGPs, then I assume
    we don't need jumbo ethernet frames for IS-IS either .....

     :p

	Henk.


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 04:27:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17302
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 04:27:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09356;
	Thu, 15 Aug 2002 04:27:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09329
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 04:27:24 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (h2s128a211n47.user.nortelnetworks.com [47.211.128.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17163
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 04:26:04 -0400 (EDT)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7F8Nxk29127
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 09:23:59 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <QNWTF156>; Thu, 15 Aug 2002 09:23:59 +0100
Message-ID: <17A46A8BD7E7D41199E300508BE3A94C05B6B534@zirey00b.europe.nortel.com>
From: "Terry Canning" <canningt@nortelnetworks.com>
To: "'isis-wg@ietf.org'" <isis-wg@ietf.org>
Date: Thu, 15 Aug 2002 09:23:58 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C24435.1A3470B8"
Subject: [Isis-wg] 3way handshake TLV & Cisco
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

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_01C24435.1A3470B8
Content-Type: text/plain;
	charset="iso-8859-1"

Folks 

I have been exmaining an point to point IIH produced by a Cisco running IOS
Version 11.0 and come across a TLV with the type value set to 0xF0. This
happens to be the same type value as the 3 way handshake TLV. As the value
in this Cisco TLV does not contain an "Extended Local Circuit ID", I can
only assume that they must be using this for a proprietary TLV. Does anyone
know anything about this?



Thanks 

Terry Canning


------_=_NextPart_001_01C24435.1A3470B8
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.2655.35">
<TITLE>3way handshake TLV &amp; Cisco </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Folks </FONT>
</P>

<P><FONT SIZE=3D2>I have been exmaining an point to point IIH produced =
by a Cisco running IOS Version 11.0 and come across a TLV with the type =
value set to 0xF0. This happens to be the same type value as the 3 way =
handshake TLV. As the value in this Cisco TLV does not contain an =
&quot;Extended Local Circuit ID&quot;, I can only assume that they must =
be using this for a proprietary TLV. Does anyone know anything about =
this?</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>Thanks </FONT>
</P>

<P><FONT SIZE=3D2>Terry Canning</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C24435.1A3470B8--

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 04:50:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17875
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 04:50:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12156;
	Thu, 15 Aug 2002 04:50:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12124
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 04:50:15 -0400 (EDT)
Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17837
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 04:48:54 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 979EEF2C44; Thu, 15 Aug 2002 01:50:13 -0700 (PDT)
To: "Terry Canning" <canningt@nortelnetworks.com>
Cc: "'isis-wg@ietf.org'" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] 3way handshake TLV & Cisco 
In-reply-to: Mail from "Terry Canning" <canningt@nortelnetworks.com> 
 dated Thu, 15 Aug 2002 09:23:58 BST
 <17A46A8BD7E7D41199E300508BE3A94C05B6B534@zirey00b.europe.nortel.com> 
Date: Thu, 15 Aug 2002 01:50:13 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20020815085013.979EEF2C44@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org


Terry,
	this is from the draft:

   Any system that supports this mechanism MUST include Adjacency
   Three-Way State field in this option. The other fields in this option
   SHOULD be included as explained below in section 3.2.

the "Extended Local Circuit ID" belong to "SHOULD", but not "MUST".

cheers.

 ] 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_01C24435.1A3470B8
 ] Content-Type: text/plain;
 ] 	charset="iso-8859-1"
 ] 
 ] Folks 
 ] 
 ] I have been exmaining an point to point IIH produced by a Cisco running IOS
 ] Version 11.0 and come across a TLV with the type value set to 0xF0. This
 ] happens to be the same type value as the 3 way handshake TLV. As the value
 ] in this Cisco TLV does not contain an "Extended Local Circuit ID", I can
 ] only assume that they must be using this for a proprietary TLV. Does anyone
 ] know anything about this?
 ] 
 ] 
 ] 
 ] Thanks 
 ] 
 ] Terry Canning
 ] 
 ] 
 ] ------_=_NextPart_001_01C24435.1A3470B8
 ] 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.2655.35">
 ] <TITLE>3way handshake TLV &amp; Cisco </TITLE>
 ] </HEAD>
 ] <BODY>
 ] 
 ] <P><FONT SIZE=3D2>Folks </FONT>
 ] </P>
 ] 
 ] <P><FONT SIZE=3D2>I have been exmaining an point to point IIH produced =
 ] by a Cisco running IOS Version 11.0 and come across a TLV with the type =
 ] value set to 0xF0. This happens to be the same type value as the 3 way =
 ] handshake TLV. As the value in this Cisco TLV does not contain an =
 ] &quot;Extended Local Circuit ID&quot;, I can only assume that they must =
 ] be using this for a proprietary TLV. Does anyone know anything about =
 ] this?</FONT></P>
 ] <BR>
 ] <BR>
 ] 
 ] <P><FONT SIZE=3D2>Thanks </FONT>
 ] </P>
 ] 
 ] <P><FONT SIZE=3D2>Terry Canning</FONT>
 ] </P>
 ] 
 ] </BODY>
 ] </HTML>
 ] ------_=_NextPart_001_01C24435.1A3470B8--
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] Isis-wg@ietf.org
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 05:04:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18405
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 05:04:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13827;
	Thu, 15 Aug 2002 05:03:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13798
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 05:03:41 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (h2s128a211n47.user.nortelnetworks.com [47.211.128.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18266
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 05:02:20 -0400 (EDT)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7F92uk10861;
	Thu, 15 Aug 2002 10:02:56 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <QNWTFGNR>; Thu, 15 Aug 2002 10:02:56 +0100
Message-ID: <17A46A8BD7E7D41199E300508BE3A94C05B6B67B@zirey00b.europe.nortel.com>
From: "Terry Canning" <canningt@nortelnetworks.com>
To: Naiming Shen <naiming@redback.com>
Cc: "'isis-wg@ietf.org'" <isis-wg@ietf.org>
Subject: RE: [Isis-wg] 3way handshake TLV & Cisco 
Date: Thu, 15 Aug 2002 10:02:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2443A.8A78EB4C"
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

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_01C2443A.8A78EB4C
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Naiming

Thanks for that.

I guess what you are saying is the the Cisco IIHs do support the 3 way
handshaking TLV however they leave out the "Extended local Circuit ID"
field. 

But what use is the handshake without this field. If you receive one of
these IIHs what should you put in the "Neighbour Extended local circuit ID"
of the IIH you reply with? Should you leave this empty and only populate the
"Neighbor System ID field"

I guess that would work OK but obviously wouldn't cover the scenario whereby
the link is moved to another interface.

What are your thoughts?

Thanks

Terry





-----Original Message-----
From: Naiming Shen [mailto:naiming@redback.com]
Sent: 15 August 2002 09:50
To: Canning, Terry [IRE07:GL52:EXCH]
Cc: 'isis-wg@ietf.org'
Subject: Re: [Isis-wg] 3way handshake TLV & Cisco 




Terry,

	this is from the draft:



   Any system that supports this mechanism MUST include Adjacency

   Three-Way State field in this option. The other fields in this option

   SHOULD be included as explained below in section 3.2.



the "Extended Local Circuit ID" belong to "SHOULD", but not "MUST".



cheers.



 ] 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_01C24435.1A3470B8

 ] Content-Type: text/plain;

 ] 	charset="iso-8859-1"

 ] 

 ] Folks 

 ] 

 ] I have been exmaining an point to point IIH produced by a Cisco running
IOS

 ] Version 11.0 and come across a TLV with the type value set to 0xF0. This

 ] happens to be the same type value as the 3 way handshake TLV. As the
value

 ] in this Cisco TLV does not contain an "Extended Local Circuit ID", I can

 ] only assume that they must be using this for a proprietary TLV. Does
anyone

 ] know anything about this?

 ] 

 ] 

 ] 

 ] Thanks 

 ] 

 ] Terry Canning

 ] 

 ] 

 ] ------_=_NextPart_001_01C24435.1A3470B8

 ] 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.2655.35">

 ] <TITLE>3way handshake TLV &amp; Cisco </TITLE>

 ] </HEAD>

 ] <BODY>

 ] 

 ] <P><FONT SIZE=3D2>Folks </FONT>

 ] </P>

 ] 

 ] <P><FONT SIZE=3D2>I have been exmaining an point to point IIH produced =

 ] by a Cisco running IOS Version 11.0 and come across a TLV with the type =

 ] value set to 0xF0. This happens to be the same type value as the 3 way =

 ] handshake TLV. As the value in this Cisco TLV does not contain an =

 ] &quot;Extended Local Circuit ID&quot;, I can only assume that they must =

 ] be using this for a proprietary TLV. Does anyone know anything about =

 ] this?</FONT></P>

 ] <BR>

 ] <BR>

 ] 

 ] <P><FONT SIZE=3D2>Thanks </FONT>

 ] </P>

 ] 

 ] <P><FONT SIZE=3D2>Terry Canning</FONT>

 ] </P>

 ] 

 ] </BODY>

 ] </HTML>

 ] ------_=_NextPart_001_01C24435.1A3470B8--

 ] 

 ] _______________________________________________

 ] Isis-wg mailing list

 ] Isis-wg@ietf.org

 ] https://www1.ietf.org/mailman/listinfo/isis-wg



- Naiming


------_=_NextPart_001_01C2443A.8A78EB4C
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.2655.35">
<TITLE>RE: [Isis-wg] 3way handshake TLV &amp; Cisco </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Naiming</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for that.</FONT>
</P>

<P><FONT SIZE=3D2>I guess what you are saying is the the Cisco IIHs do =
support the 3 way handshaking TLV however they leave out the =
&quot;Extended local Circuit ID&quot; field. </FONT></P>

<P><FONT SIZE=3D2>But what use is the handshake without this field. If =
you receive one of these IIHs what should you put in the =
&quot;Neighbour Extended local circuit ID&quot; of the IIH you reply =
with? Should you leave this empty and only populate the &quot;Neighbor =
System ID field&quot;</FONT></P>

<P><FONT SIZE=3D2>I guess that would work OK but obviously wouldn't =
cover the scenario whereby the link is moved to another =
interface.</FONT>
</P>

<P><FONT SIZE=3D2>What are your thoughts?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
</P>

<P><FONT SIZE=3D2>Terry</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Naiming Shen [<A =
HREF=3D"mailto:naiming@redback.com">mailto:naiming@redback.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: 15 August 2002 09:50</FONT>
<BR><FONT SIZE=3D2>To: Canning, Terry [IRE07:GL52:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'isis-wg@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Isis-wg] 3way handshake TLV &amp; =
Cisco </FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Terry,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>this is =
from the draft:</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Any system that supports this mechanism =
MUST include Adjacency</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Three-Way State field in this option. =
The other fields in this option</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; SHOULD be included as explained below in =
section 3.2.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>the &quot;Extended Local Circuit ID&quot; belong to =
&quot;SHOULD&quot;, but not &quot;MUST&quot;.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>cheers.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;] This message is in MIME format. Since your =
mail reader does not understand</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] this format, some or all of this message may =
not be legible.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] =
------_=3D_NextPart_001_01C24435.1A3470B8</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Content-Type: text/plain;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &nbsp;&nbsp;&nbsp;&nbsp; =
charset=3D&quot;iso-8859-1&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Folks </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] I have been exmaining an point to point IIH =
produced by a Cisco running IOS</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Version 11.0 and come across a TLV with the =
type value set to 0xF0. This</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] happens to be the same type value as the 3 =
way handshake TLV. As the value</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] in this Cisco TLV does not contain an =
&quot;Extended Local Circuit ID&quot;, I can</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] only assume that they must be using this for =
a proprietary TLV. Does anyone</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] know anything about this?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Thanks </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Terry Canning</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] =
------_=3D_NextPart_001_01C24435.1A3470B8</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Content-Type: text/html;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &nbsp;&nbsp;&nbsp;&nbsp; =
charset=3D&quot;iso-8859-1&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Content-Transfer-Encoding: =
quoted-printable</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD =
HTML 3.2//EN&quot;&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;HTML&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;HEAD&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;META =
HTTP-EQUIV=3D3D&quot;Content-Type&quot; CONTENT=3D3D&quot;text/html; =
=3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] charset=3D3Diso-8859-1&quot;&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;META NAME=3D3D&quot;Generator&quot; =
CONTENT=3D3D&quot;MS Exchange Server version =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] 5.5.2655.35&quot;&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;TITLE&gt;3way handshake TLV &amp;amp; =
Cisco &lt;/TITLE&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/HEAD&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;BODY&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;P&gt;&lt;FONT SIZE=3D3D2&gt;Folks =
&lt;/FONT&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/P&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;P&gt;&lt;FONT SIZE=3D3D2&gt;I have been =
exmaining an point to point IIH produced =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] by a Cisco running IOS Version 11.0 and come =
across a TLV with the type =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] value set to 0xF0. This happens to be the =
same type value as the 3 way =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] handshake TLV. As the value in this Cisco TLV =
does not contain an =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &amp;quot;Extended Local Circuit =
ID&amp;quot;, I can only assume that they must =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] be using this for a proprietary TLV. Does =
anyone know anything about =3D</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] this?&lt;/FONT&gt;&lt;/P&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;BR&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;BR&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;P&gt;&lt;FONT SIZE=3D3D2&gt;Thanks =
&lt;/FONT&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/P&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;P&gt;&lt;FONT SIZE=3D3D2&gt;Terry =
Canning&lt;/FONT&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/P&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/BODY&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] &lt;/HTML&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] =
------_=3D_NextPart_001_01C24435.1A3470B8--</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] =
_______________________________________________</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Isis-wg mailing list</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] Isis-wg@ietf.org</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;] <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isis-wg" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isis-wg</A></FO=
NT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>- Naiming</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2443A.8A78EB4C--

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 08:18:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22330
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 08:18:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25052;
	Thu, 15 Aug 2002 08:16:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25019
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 08:16:47 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21876;
	Thu, 15 Aug 2002 08:15:26 -0400 (EDT)
Message-Id: <200208151215.IAA21876@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: isis-wg@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 15 Aug 2002 08:15:26 -0400
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-09.txt
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

--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		: Management Information Base for IS-IS
	Author(s)	: J. Parker
	Filename	: draft-ietf-isis-wg-mib-09.txt
	Pages		: 83
	Date		: 14-Aug-02
	
This document describes a management information base for the IS-IS
Routing protocol, as described in ISO 10589 [2], when it is used to
construct routing tables for IP networks, as described in RFC 1195
[RFC1195].
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.
This memo is based on an IETF draft by Chris Gunner [1].  This
version has been modified to include MIB-II syntax, to exclude
portions of the protocol that are not relevant to IP, such as the
ES-IS protocol, and to add management support for current practice.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-wg-mib-09.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-wg-mib-09.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:	<20020814134833.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-isis-wg-mib-09.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 12:02:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02543
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 12:02:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08963;
	Thu, 15 Aug 2002 11:57:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08932
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 11:57:35 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02068
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 11:56:15 -0400 (EDT)
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7FFv5m05253;
	Thu, 15 Aug 2002 08:57:05 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost)
	by cirrus.juniper.net (8.11.6/8.11.6) id g7FFv5W69022;
	Thu, 15 Aug 2002 08:57:05 -0700 (PDT)
	(envelope-from dkatz@cirrus.juniper.net)
Date: Thu, 15 Aug 2002 08:57:05 -0700 (PDT)
Message-Id: <200208151557.g7FFv5W69022@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: canningt@nortelnetworks.com
CC: naiming@redback.com, isis-wg@ietf.org
In-reply-to: 
	<17A46A8BD7E7D41199E300508BE3A94C05B6B67B@zirey00b.europe.nortel.com>
	(canningt@nortelnetworks.com)
Subject: Re: [Isis-wg] 3way handshake TLV & Cisco
References:  <17A46A8BD7E7D41199E300508BE3A94C05B6B67B@zirey00b.europe.nortel.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

This is backward compatibility to the original 3-way proposal, which only
had the state field.  The introduction in the draft describes the scenarios
in which this was (and still is) useful even without the extra gorp.

--Dave

   I guess what you are saying is the the Cisco IIHs do support the 3 way
   handshaking TLV however they leave out the "Extended local Circuit ID"
   field. 

   But what use is the handshake without this field. If you receive one of
   these IIHs what should you put in the "Neighbour Extended local circuit ID"
   of the IIH you reply with? Should you leave this empty and only populate the
   "Neighbor System ID field"

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Aug 15 15:40:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12955
	for <isis-archive@odin.ietf.org>; Thu, 15 Aug 2002 15:40:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29663;
	Thu, 15 Aug 2002 15:34:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29630
	for <isis-wg@optimus.ietf.org>; Thu, 15 Aug 2002 15:34:06 -0400 (EDT)
Received: from net4u.net4u.ch (root@net4u.net4u.ch [194.191.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12593
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 15:32:45 -0400 (EDT)
Received: from net4u.ch (gw.xebeo.com [204.192.44.242])
	by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id g7FJXRG06330;
	Thu, 15 Aug 2002 21:33:27 +0200
Message-ID: <3D5BFD33.30909@net4u.ch>
Date: Thu, 15 Aug 2002 12:12:51 -0700
From: Tony Przygienda <prz@net4u.ch>
Reply-To: prz@net4u.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Learman <jlearman@cisco.com>
CC: Alex Zinin <zinin@psg.com>,
        Radia Perlman - Boston Center for Networking
 <Radia.Perlman@sun.com>,
        isis-wg@ietf.org
Subject: Re: [Isis-wg] new potential issue with Proprietary / Private   TLV
 numbers?
References: <200207231954.g6NJseL11510@sydney.East.Sun.COM> <200207231954.g6NJseL11510@sydney.East.Sun.COM> <4.3.2.7.2.20020724023344.022b7478@dingdong.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org
Content-Transfer-Encoding: 7bit

Jeff Learman wrote:

>Well put.  It could be the shortest useful RFC ever! 
>
>At 10:00 PM 7/23/2002, Alex Zinin wrote:
>
>>Radia, folks
>>
>>I don't think there's much to be worried about here.
>>The IESG should have a detailed explanation of its position
>>on this issue later (I'll forward it to the list).
>>
>>My recommendation regarding the draft would be to emphasize
>>that understanding of this TLV is not required for interoperability
>>and that implementations must not use the contents of this TLV
>>to affect their routing table calculation.
>>


So given this addition, are the authors of the draft (Philip) ready to 
submit it. I think
it would be usefull in couple of respects ...

    --- tony


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Fri Aug 16 02:15:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06925
	for <isis-archive@odin.ietf.org>; Fri, 16 Aug 2002 02:15:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11889;
	Fri, 16 Aug 2002 02:14:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11860
	for <isis-wg@optimus.ietf.org>; Fri, 16 Aug 2002 02:14:58 -0400 (EDT)
Received: from titanium (mail.ipinfusion.com [65.223.109.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06839
	for <isis-wg@ietf.org>; Fri, 16 Aug 2002 02:13:37 -0400 (EDT)
Received: from titanium ([127.0.0.1] helo=titanium.ipinfusion.com)
	by titanium with esmtp (Exim 3.35 #1 (Debian))
	id 17faNu-0002OB-00
	for <isis-wg@ietf.org>; Thu, 15 Aug 2002 23:14:58 -0700
Date: Thu, 15 Aug 2002 23:14:58 -0700
Message-ID: <878z371g9p.wl@ipinfusion.com>
From: Noguchi Kay <kay@ipinfusion.com>
To: isis-wg@ietf.org
Subject: Re: [Isis-wg] isisISAdjProtSuppEntry index
In-Reply-To: <EB5FFC72F183D411B38200062957342901E57C0D@r2d2.axiowave.com>
References: <EB5FFC72F183D411B38200062957342901E57C0D@r2d2.axiowave.com>
User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
X-BeenThere: isis-wg@ietf.org

Hi Jeff,

It's cool to use isisISAdjProtSuppProtocol as the index of
isisISAdjProtSuppEntry as you pointed out in the new draft
like isisSysProtSuppEntry.

Thank you,

								kay

> Kay -
> 
> I have checked my current copy of the MIB.  Someone else
> has suggested the change to to use the ISAdjIndex.  The
> current table is shown below.
> 
> Help me understand how a ProtSuppIndex will be an
> improvement over simply listing the protocols 
> supported.  The protocols are one byte values,
> and should be easy to walk such a table.  
> 
> - jeff parker
> 
>      isisISAdjProtSuppEntry OBJECT-TYPE
>         SYNTAX IsisISAdjProtSuppEntry
>         MAX-ACCESS not-accessible
>         STATUS current
>         DESCRIPTION
>             "Each entry contains one protocol supported by a
>              neighboring Intermediate System as reported in its IIH
>              PDUs."
>         INDEX {  isisSysInstance,
>             isisCircIndex,
>             isisISAdjIndex,
>             isisISAdjProtSuppProtocol }
>     ::= { isisISAdjProtSuppTable 1 }
> 
>     IsisISAdjProtSuppEntry ::=
>         SEQUENCE {
>             isisISAdjProtSuppProtocol
>                 SupportedProtocol
>         }

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg