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

"Philip Christian" <philip.christian@iname.com> Wed, 05 February 2003 10:23 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 FAA16140 for <isis-wg-archive@odin.ietf.org>; Wed, 5 Feb 2003 05:23:08 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15AT2n12045 for isis-wg-archive@odin.ietf.org; Wed, 5 Feb 2003 05:29:02 -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 h15AT2J12042 for <isis-wg-web-archive@optimus.ietf.org>; Wed, 5 Feb 2003 05:29:02 -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 FAA16133 for <isis-wg-web-archive@ietf.org>; Wed, 5 Feb 2003 05:22:36 -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 h15ARfJ11962; Wed, 5 Feb 2003 05:27:41 -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 h15AQVJ11921 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 05:26:31 -0500
Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16065 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 05:20:05 -0500 (EST)
Received: (qmail 10573 invoked from network); 5 Feb 2003 10:23:39 -0000
Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 5 Feb 2003 10:23:39 -0000
Received: (qmail 45013 invoked from network); 5 Feb 2003 10:23:35 -0000
Received: from unknown (HELO ws1-3.us4.outblaze.com) (205.158.62.55) by 205-158-62-153.outblaze.com with SMTP; 5 Feb 2003 10:23:34 -0000
Received: (qmail 15337 invoked by uid 1001); 5 Feb 2003 10:23:34 -0000
Message-ID: <20030205102334.15336.qmail@iname.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [149.254.120.136] by ws1-3.us4.outblaze.com with http for philip.christian@iname.com; Wed, 05 Feb 2003 10:23:34 +0000
From: Philip Christian <philip.christian@iname.com>
To: naiming@redback.com, kay@ipinfusion.com
Cc: sprevidi@cisco.com, isis-wg@ietf.org
Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt
X-Originating-Ip: 149.254.120.136
X-Originating-Server: ws1-3.us4.outblaze.com
Content-Transfer-Encoding: 7bit
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: Wed, 05 Feb 2003 10:23:34 +0000
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I also have serious problems with this draft.

1. Integrated IS-IS was originally architected as an "Integrated" routing protocol to route both CLNP and IPv4 in a single SPF.  The problem of running IPv4 and IPv6 together is not a new problem, it is actually exactly the same one that RFC 1195 was originally written to deal with (but with v4 and CLNP).  Integrated IS-IS will work just as well with v4 and v6 as it did with v4 and CLNP.  This draft attempts to unravel this behaviour by having separate SPFs.  This is contrary to the original architecture of Integrated IS-IS (it isn't even "integrated") and contrary to section 3.10 of RFC 1195 where it says

   "The Dijkstra computation does not take into consideration whether a
   router is IP-only, OSI-only, or dual. The topological restrictions
   specified in section 1.4 ensure that IP packets will only be sent via
   IP-capable routers, and OSI packets will only be sent via OSI-capable
   routers."

This is not just some detail, but a fundamental behaviour of the protocol.

Consequently there is no interoperability between this draft and RFC 1195.

2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it.  You could put all of the v4 nodes in one area and all the v6 nodes in another.  Then you could just make a dual router with two SPFs that participates in both areas.  Or you could use the existing MT draft.  Or you could just use OSPF.

3. The draft isn't even honest enough to state that it will not interoperate with existing RFC 1195 implementations, nor with G.7712, nor with auto-encap.  If there is some non-interoperability introduced then it should be clearly stated up front.

Regards, Philip Christian



----- Original Message -----
From: Naiming Shen <naiming@redback.com>
Date: Tue, 04 Feb 2003 22:42:21 -0800 
To: Noguchi Kay <kay@ipinfusion.com>
Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt 


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

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

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