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

[Jeff Learman <[e-mail]>]

At 05:23 AM 2/5/2003, 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.
>
>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

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


_______________________________________________
Isis-wg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/isis-wg