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

From: "Philip Christian" <[email-masked]>
Date: Thu, 19 Sep 2002 16:00:41 +0000

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

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

---

From: Jeff Learman <[email-masked]>
Date: Thu, 19 Sep 2002 15:04:05 -0400

>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 rout…

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:

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