Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt

Naiming Shen <naiming@redback.com> Wed, 05 February 2003 06:44 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17912 for <isis-wg-archive@odin.ietf.org>; Wed, 5 Feb 2003 01:44:59 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h156olR22646 for isis-wg-archive@odin.ietf.org; Wed, 5 Feb 2003 01:50:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h156olJ22643 for <isis-wg-web-archive@optimus.ietf.org>; Wed, 5 Feb 2003 01:50:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17903 for <isis-wg-web-archive@ietf.org>; Wed, 5 Feb 2003 01:44:27 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h156mqJ22554; Wed, 5 Feb 2003 01:48:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h156j4J22485 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 01:45:04 -0500
Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17792 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 01:38:43 -0500 (EST)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 472B83FAC8; Tue, 4 Feb 2003 22:42:21 -0800 (PST)
To: Noguchi Kay <kay@ipinfusion.com>
Cc: stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org
Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt
In-reply-to: Mail from Noguchi Kay <kay@ipinfusion.com> dated Tue, 04 Feb 2003 13:53:51 PST <87hebjiufk.wl@giga.kayz.org>
From: Naiming Shen <naiming@redback.com>
Message-Id: <20030205064221.472B83FAC8@prattle.redback.com>
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/isis-wg/>
Date: Tue, 04 Feb 2003 22:42:21 -0800

Hi Kay,

 ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for
 ] > IPv6.
 ] 
 ] 	Two questions for this.
 ] 
 ] 	1) How to get the "all the possible NLPIDs" and what is the value
 ] 	   which M-ISIS software only support IPv6 puts in for this case?
 ] 
 ] 	   IPv4 and IPv6 NLPIDs or IPv4 NLPID only?

NLPIDs for both v4 and v6. the adjacency status will be determined by
the MT status.

 ] 
 ] 	2) Some implementation checks if the IP Interface Address TLV is
 ] 	   in the same subnetwork or not to form an adjacency as
 ] 	   stated in draft-ietf-isis-ip-interoperable-00.txt section 13.
 ] 
 ] 	   How does M-ISIS software which only supports IPv6 get the IPv4
 ] 	   subnetwork information for this link?

as you noticed, this is an implementation issue. and get aournd those
implementation, one can assign an ipv4 address on the LAN interface,
and "inject" that ipv4 address in the IIH which is on the same subnet
as your neighbors. as far as i know, there is no ipv6 only routers yet,
get an ipv4 address on the LAN interface does not mean the router
need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node.

for any new routing scheme, we can not expect a flag day to upgrage
all the nodes with new software. any scheme HAS to co-exist with the
current/legacy software. new software has the flexibility to do "tricks"
to work with the old software.

going forward, as i mentioned in my previous email post, it's better
to get rid of the restriction on setting up LAN adjacencies. just set
up them all, to use them or not, it's a local issue(e.g. if the node does
not like neighbor's IP subnet, then don't put a pnode tlv in it's lsp).

Les has answered the below question.

thanks.

 ] 
 ] > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4
 ] > neighbor will fail on backlink check during the SPF, thus will not
 ] > use you as a nexthop.
 ] 
 ] 	I know OSPFv2 specification has the "link back check" in 
 ] 	the spec, RFC 2328 section 16.1(p. 163).
 ] 
 ] 	But I didn't see it in ISO 10589 nor RFC 1195.
 ] 
 ] 	Could you point out where it's documented or is that an
 ] 	unwritten spec?

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