Subject: RE: [Isis-wg] Protocols Supported TLV

From: "Philip Christian" <[email-masked]>
Date: Fri, 20 Sep 2002 09:01:00 +0000

Jeff,
Do you mean something like this (view in courier)? :-

  OSI_ES--OSIonly--Dual--Dual--OSIonly--OSI_ES
                     Š     Š
                     Š     Š
  IP_host--IPonly--Dual--Dual--IPonly--IP_host   

Such a network doesn't follow RFC 1195 restrictions, but it will work.  Protocol aware SPF isn't "necessary" to make it work.

I will accept that there are other topologies which wouldn't work, and where multi-SPF could make it work.  However in such a network you would have to be very careful about putting in a vanilla RFC 1195 dual router, because you might easily introduce loops and blackholes.

My point is that Integrated IS-IS was architected right from the start to have a single SPF for multiple network-layer protocols.  If we try to unravel this fundamental principle ten years on then we are going to get in an awful mess.

The type of network that I show was documented as working back in 1994 in a draft.  Read case "A" of
http://www.watersprings.org/pub/id/draft-ietf-isis-opexp-01.txt

Philip

----- Original Message -----
From: Jeff Learman 
Date: Thu, 19 Sep 2002 15:04:05 -0400
To: "Philip Christian" 
Subject: RE: [Isis-wg] Protocols Supported TLV

I agree with everything except:

The only ways that I can think of making multi-SPF useful is to actually put the two instances in two seperate areas; eg run proto-A in area 0001 and proto-B in area 0002, or, to say that every router in the area must have protocol aware SPF (unluckily this isn't backwards compatible with existing implementations).

Multi-SPF is necessary when you have mixed areas that don't follow 1195
restrictions, but have sufficient connectivity for all communicating
pairs to reach each other over routers that support their protocol.

I'm not advocating this, I'm just stating it because it's true.
I don't even remember why we're discussing this, but since the
"options" arose, I felt it necessary to explain some details of the
options that weren't mentioned.

Regards,
Jeff

At 12:00 PM 9/19/2002, Philip Christian wrote:

This is a different subject, about which Jeff and I have a difference of opinion (I think).  I'm going to rise to the bait though :-)

The problem with protocol aware multi-SPF is that it is not compatible with auto-encap.  Auto-encap actually relies on routers NOT being protocol aware, and blindly sending stuff towards the auto-encap routers, which of cause then forward packets that would have been lost if it wasn't for their dynamic tunnelling capability.

Shame that Jeff and I have come up with valid but non-compatible solutions to the same problem...  Jeff's way is (in effect) how it is done with OSPF, with an OSPFv2 instance for the IPv4 and an OSPFv3 instance for the IPv6. Demonstrably that does work.

That said, you cannot safely have a protocol aware multi-SPF router in the same domain as a traditional RFC 1195 dual router, and then break the RFC 1195 topological rules.  If you cannot break the topological rules, then what is the point in having multi-SPFs ?

I will explain.

If all of the routers in a domain are dual, then a mult-SPF dual router will come up with the same answer for both Proto-A and Proto-B destinations.  All routers are dual and so the calculated shortest path must be the same.  This is safe, but there is no point in multi-SPF in this scenario, you just don't need it.

If all the routers in a domain are NOT dual, then a multi-SPF dual router might calculate a different path for Proto-A to the one it calculates for Proto-B.  In that same domain there might be another dual router that is vanilla RFC 1195.  That router now calculates a different path for one or the other protos to what the the multi-SPF router calculated.

The result will be routing loops and blackholes as the vanilla dual and the multi-SPF dual came up with differing shortest paths.

The only ways that I can think of making multi-SPF useful is to actually put the two instances in two seperate areas; eg run proto-A in area 0001 and proto-B in area 0002, or, to say that every router in the area must have protocol aware SPF (unluckily this isn't backwards compatible with existing implementations).

The important point with auto-encap is that it does not alter the shortest path to any destination compared with that calculated by vanilla RFC 1195.  For any destination an auto-encap router will come up with the same next hop as a normal RFC 1195 router.  Thus we get backwards compatibility, and no loops.  What auto-encap does is to send packets down the same shortest path that RFC 1195 / ISO 10589 would, but it alters the protocol of the packets so that they can make the journey without being dumped.

Philip

Snip

For this to work,
multiprotocol routers have to run separate SPFs for each protocol,
while assuming that all pseudonode LSPs support all protocols.

Regards,
Jeff

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: Jeff Learman <[email-masked]>
Date: Fri, 20 Sep 2002 10:04:07 -0400

If by "protocol-aware SPF" you mean the same thing as "multi-SPF", then
I really shouldn't have disagreed with that paragraph I quoted.

My understanding was that there were implementations that used
multi-SPF, but I don't remember which, or why I got that impression,
other than that it was through discussion on this forum.  I don't
know whether Cisco routers use multi-SPF, for example.

You're right of course that all implementations in a mixed subdomain
would ave to support multi-SPF.  In the same vein, you have to be
equally careful in auto-encap not to have "vanilla 1195 IP-only" and
"vanilla OSI-only" routers on a LAN, because they will form
adjacencies between each other.  I think that will mess things up.

I'm not recommending that we add this to the interop document, by the way.

Tangentially, I do have some issues with auto-encap -- not for IP/OSI,
but for IPV4/V6.  Is it possible, with auto-encap, to explicitly control
where tunnel endpoints are allowed to exist?  This would be extremely
important in a real rollout of IPV6, because only certain platforms
will be able to do the tunneling at line rate.  Also, I think it will
be important to make sure that automatic tunneling doesn't happen when
there is a pure-native path that might be slightly longer than a mixed
path.  (If you reply to this you can change the subject accordingly.)

Note that this concern doesn't necessarily represent a Cisco position;
I haven't discussed it with anyone here.

Regards,
Jeff

At 05:01 AM 9/20/2002, Philip Christian wrote:
>                     ¦     ¦
>                     ¦     ¦