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

From: "Philip Christian" <[email-masked]>
Date: Thu, 19 Sep 2002 09:06:21 +0000

As Ruth says, there are three options open to us (wrt Protocols Supported field in Hellos):-

1. Ignore it.

2. Only form adjacency if there is an overlap of one or more.

3. Only form adjacency if there is exact match.

Sadly there is no perfect answer...

Option 1 always allows you to build a network, but a network designer has to be careful as it will allow him to build blackholes into the network.

Option 2 only rejects totally useless adjacencies, and so this is why the ITU-T went for this.  Also a certain large(st) vendor had already put this in their implementation and it seems to make sense.

Option 3 is idiot proof in the sense that it stops you from getting blackholes, but it also prevents you from building a topology which is perfectly valid.  If you read RFC 1195 then you see that it is allowable to put a dual router into an OSI-only area, because that dual router can forward OSI packets perfectly well.  Therefore option 3 is probably too restrictive.

Thinking about an IPv6 migration for example.  If you have an existing IP4 network then it is perfectly valid to start adding IPv4 / IPv6 dual routers to it (or upgrading the ones that you have), one at a time.  It might take you months or years to upgrade them all.  Once you have upgraded them all then you can declare it to now be an IPv4 / IPv6 dual area and start forwarding IPv6 traffic on it too.  Option 1 and 2 allow this, but 3 doesn't.

Of course if you go for automatic encapsulation then you don't even need to finish upgrading them all before you can start sending IPv6 :-)  See http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-02.txt for more details.

Philip

----- Original Message -----
From: Jeff Learman
Date: Wed, 18 Sep 2002 13:31:52 -0400
To: Les Ginsberg
Subject: RE: [Isis-wg] Protocols Supported TLV

Good point, Les, but we should at least warn folks that this is
not a plug-and-play situation.  I agree we shouldn't attempt to
solve it, just point out the problem and mention that it can be
worked around by configuring DR priorities.

At 01:07 PM 9/18/2002, Les Ginsberg wrote:

At 11:45 AM 9/18/02 -0400, Jeff Learman wrote:

>
>One of the sticky points is what happens
>with DIS election on a LAN - you can get into
>situations where not everyone can talk to the DIS,
>or where you have dueling DISs.  It seems that
>discussion of this issue was left on the
>cutting room floor.

I'm surprised I let that happen, since this was my mantra for a while.
I'll see if I can come up with a paragraph to fit in context.

Actually I believe we deliberately left out discussion of this issue because we knew that the ITU work and the associated auto-encapsulation draft work being done by Philip were addressing this issue and we didn't want to do a disservice by having either an incomplete discussion or a solution which differed from what was eventually settled on by the other work. Hence the statement in the section from http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt which Jeff P quoted:

"However, the behavior of mixed networks that do not fol-
low these guidelines is not well defined."

Section 5.1 of Philip's latest draft  (draft-ietf-isis-auto-encap-02.txt) addresses this issue quite well.

Les

--

_______________________________________________

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 10:10:11 -0400

Option 1 is what 1195 says to do.  It works fine in networks that
follow 1195's topology restrictions (if you want protocol X in a
subdomain, all routers in the subdomain must support protocol X).

Option 2 allows the auto-encapsulation option.

Either option 1 or option 2 work in a mixed network that has
sufficient connectivity for all supported protocols but does not
conform to 1195's restrictions.  However, for either option to work,
DR priorities must be configured so that on any LAN with multiple
protocols, the DR elected must support all protocols.  (That's an
oversimplification, but it's sufficient.)  By "suffiently connected"
I mean that there is a network path supporting protocol X between any
two entities that communicate using protocol X.  For this to work,
multiprotocol routers have to run separate SPFs for each protocol,
while assuming that all pseudonode LSPs support all protocols.

Option 3 has serious disadvantages and no significant advantages.

Regards,
Jeff

At 05:06 AM 9/19/2002, Philip Christian wrote:

>Of course if you go for automatic encapsulation then you don't even need to finish upgrading them all before you can start sending IPv6 :-)  See <http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-02.txt for more details.
>
>Philip
>
>
>
>>Actually I believe we deliberately left out discussion of this issue because we knew that the ITU work and the associated auto-encapsulation draft work being done by Philip were addressing this issue and we didn't want to do a disservice by having either an incomplete discussion or a solution which differed from what was eventually settled on by the other work. Hence the statement in the section from <http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt>http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt which Jeff P quoted:
>>
>Sign-up for your own FREE Personalized E-mail at <http://www.mail.com/?sr=signup>Mail.com
>_______________________________________________ Isis-wg mailing list [email-masked] https://www1.ietf.org/mailman/listinfo/isis-wg