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

From: "Philip Christian" <[email-masked]>
Date: Wed, 05 Feb 2003 10:23:34 +0000

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 <[email-masked]>
Date: Tue, 04 Feb 2003 22:42:21 -0800 
To: Noguchi Kay <[email-masked]>
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
[email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 5 Feb 2003 12:14:42 +0100

On Wed, Feb 05, 2003 at 10:23:34AM +0000, Philip Christian wrote:
| 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.
                                                  ^^^^^^^^^

i'd call it a fundamental flaw - 
stating "all nodes have to support all the protocols" is practically
speaking non-sense as it ignores the fact that large networks cannot
be transitioned on a flag-day;
today, the main purpose of the MT today is incremental transition;

| 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.

on a 600+ router L2 network ?

| 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.

compliance to rfc1195, which is flawed in that respect, is not desired;

/hannes

---

From: Jeff Learman <[email-masked]>
Date: Wed, 05 Feb 2003 09:13:42 -0500

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

I disagree.  An implementation that runs multiple SPFs will interoperate
perfectly with one that doesn't in any topology that meets 1195's
deployment restrictions, so there is NO interoperability problem until
you go BEYOND RFC-1195.

I have long been a supporter of running multiple SPFs (personally, not
as a spokesman for Cisco).  However, it is clear to me that there is
little or no support for this idea among router vendors.

My suspicion now is that many IPV4/IPV6 migration issues can be
mitigated by use of MPLS, and new complex schemes to allow arbitrary
topologies are unnecessary.

Regards,
Jeff

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 5 Feb 2003 17:01:07 +0100

On Wed, Feb 05, 2003 at 09:13:42AM -0500, Jeff Learman wrote:
| >Consequently there is no interoperability between this draft and RFC 1195.
| 
| I disagree.  An implementation that runs multiple SPFs will interoperate
| perfectly with one that doesn't in any topology that meets 1195's
| deployment restrictions, so there is NO interoperability problem until
| you go BEYOND RFC-1195.
| 
| I have long been a supporter of running multiple SPFs (personally, not
| as a spokesman for Cisco).  However, it is clear to me that there is
| little or no support for this idea among router vendors.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

i know about at least one implementation which supports per-topo SPF runs ;-)

/hannes