Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

From: Vishwas Manral <[email-masked]>
Date: Wed, 16 Mar 2005 23:13:49 -0800

Hi Acee,

I agree we need to be very particular about defining any new link types,
I was just giving Alex examples of what can go in(based on what is there
in the sister Link State(IS-IS) protocol.

Alex,

>> Wouldn't something like
>> http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt
>> fit better in the Router-LSA?
>Putting it in router-LSAs wouldn't be my design choice.
It is made a part of the Reachability-TLV in IS-IS, which in my view is
similar to the Router LSA.

> With all this in mind, I don't see how this would do us any good.
If someone wants to write an implementation of OSPF, what does he/she do
regarding unknown link types? We need to define the behavior else we
will never get interoperability. I guess we both agree with the above.

If I understood the discussion in the mailing list right, most
implementations ignore the link and that is what we are trying to
standardize. The suggestion you make will not interoperate with the
installed base at all while a MUST ignore solution will with most of
them. Besides it seems to me (from Acee's mail) that we may not be
looking for a heavier solution.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Wednesday, March 16, 2005 7:27 PM
To: [email-masked]
Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

Vishwas Manral wrote:

>Alex,
>
>Wouldn't something like
>http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt
>fit better in the Router-LSA?
>  
>
Vishwas,

Irrespective of how we decide to document the handling of unknown link 
types, I don't
like the idea of defining new link types and stuffing non-link 
information in them. If it
looks, smells, feels, and tastes like a hack it probably is one.
For OSPFv3, some of us are trying to move the WG in the direction of 
TLVs. I
made a presentation on this at the last IETF.

Thanks,
Acee

>Besides let us not forget, leaving things as is can cause routing
loops.
>So the main aim of the draft is to specify the behavior in case of
>unknown link. Extensions and further enhancements should be done taking
>care of the backward compatibility is all we are saying.
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: Mailing List [mailto:[email-masked]] On Behalf Of Alex
>Zinin
>Sent: Wednesday, March 16, 2005 12:44 PM
>To: [email-masked]
>Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02
>
>Vishwas,
>
>  Why are those "messages for informational purposes" better fit for
>router-LSAs
>  than the TE attributes that we send in opaque-LSAs?
>

---

From: Alex Zinin <[email-masked]>
Date: Thu, 17 Mar 2005 09:49:06 -0800

Vishwas,

I'll try one more time.

> regarding unknown link types?

We discussed this earlier in this thread.

> We need to define the behavior else we

We do NOT have an interoperability issue unless we start deliberately
introducing new link types without making sure everyone understands them.

> standardize.

A few years ago we had a discussion that touched on link records. John mentioned
that there are still implementations out there that will ignore the whole LSA
when the see an unknown link type. I don't think we can ignore this.

> The suggestion you make will not interoperate with the
> them.

I don't understand what you mean by "will not interoperate".

Alex

---

From: Acee Lindem <[email-masked]>
Date: Sat, 19 Mar 2005 09:16:27 -0500

Hi Alex,
I don't feel that strongly on whether or not we need to document the
behavior when an unknown link type is encountered. However, I was
content to ignore them and leave the backward compatibility issues
to those proposing new link types. If there were compelling reasons to
introduce a new link type we are now relegated to a solution where we
need protocol mechanisms to assure that every router in the area understands
it prior to it's usage and, depending on the link type, this may be more
conservative than what is needed.

Thanks,
Acee

---

From: Alex Zinin <[email-masked]>
Date: Tue, 29 Mar 2005 15:26:58 -0800

Acee, et al-

  After thinking more about this:

  We all seem to agree new link types explicitly affecting route calculation
  will need to ensure everyone in the area understands them. The remaining
  question is whether other things (those that we believe shouldn't affect
  normal route calculation) will trigger an unwanted reaction or not. The crux
  of the matter here is two-fold:

    - redefining the "unknown link-type" situation from an exception with
      unspecified processing to a normal situation with a well-defined behavior

    - whether such redefinition will be effective 'ex post facto', given
      current protocol deployments, and what are the worst-case scenarios

  One of the questions here is whether we sure there are no networks deployed
  out there that will react to an unknown link-type (when a newer router gets
  its SW upgraded) by ignoring the whole router-LSA as John suggested, or
  screaming loudly.

  Leaving this in the capable hands of this WG now.

-- 
Alex
http://www.psg.com/~zinin

---

From: Dave Katz <[email-masked]>
Date: Tue, 29 Mar 2005 18:08:13 -0700

>       current protocol deployments, and what are the worst-case 

Until a new link type is specified, the worst case scenario is that 
somebody will build a router tester that sends undefined link types and 
well meaning people will harass zero or more vendors, who will not be 
able to do anything about their deployed base.

If a new link type is defined, the possible scenarios range from no 
issues at all, to broken routing, to crashes in "show" commands, to 
wholesale network collapses (unlikely, but fun to watch from a safe 
distance.)
>   its SW upgraded) by ignoring the whole router-LSA as John suggested, 

There is no way of knowing this.  Judging from the questions on this 
list over the years, the number of implementations is essentially 
unbounded.

One of the dominant implementations will silently skip the bad link 
type and go on to the next link.  Can't speak for the other one.

It's worth defining what to do in this case, but it is essentially 
academic until a new link type is defined.  Unfortunately, it will have 
little effect on the eventual outcome if that happens, given that it's 
15 years too late.

--Dave

---

From: Erblichs <[email-masked]>
Date: Tue, 29 Mar 2005 17:22:30 -0800

in the land of the giants...

	Don't we think that some testers has already
	generated undefined link types to make sure
	that their implementation doesn't crash?

	Thus, my worst fear is that some routers
	will create different LSDBs from others,
	these non synch LSDBs will create periodic
	black holes, etc AND NOBODY  is aware 
	that this is happening...

	Mitchell Erblich
	-------------------------

---

From: Acee Lindem <[email-masked]>
Date: Tue, 29 Mar 2005 20:58:40 -0500

Hi Alex,

Alex Zinin wrote:

>  normal route calculation) will trigger an unwanted reaction or not.
>
And I believe we agree that isn't desirable to handle the addition of 
all possible future link types in
this draft since due to simply fact that different link types may 
require different compatibility considerations.

> The crux
          - whether such redefinition will be effective 'ex post facto', 
given
            current protocol deployments, and what are the worst-case 
scenarios

At least defining the rules would provide a migration path if vendors 
and open source
developers follow the rules. If we can't agree that this is a good thing 
to do then I guess
the default action is to maintain the status quo of  leaving it 
undefined. At least initially,
the concensus was to ignore the unknown link types.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 29 Mar 2005 21:07:45 -0500

Hi Dave,

Dave Katz wrote:

> somebody will build a router tester that sends undefined link types 
> and well meaning people will harass zero or more vendors, who will not 
> be able to do anything about their deployed base.
>

Since this is what Vishwas' draft recommends, can we take this as a vote 
for adoption
of his draft :^) ?

> academic until a new link type is defined.  Unfortunately, it will 
> have little effect on the eventual outcome if that happens, given that 
> it's 15 years too late.

It is true that this is late but at least it would provide a migration 
path. In a perfect
world, an OSPF routing domain is under a single administrative authority 
and that
authority should have some control over what is deployed.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 29 Mar 2005 21:09:17 -0500

Hi Mitchell,

>	that this is happening...
We will not allow any new link types to be standardised without addressing
backward compatibility concerns.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 29 Mar 2005 19:48:49 -0800

Acee,

> And I believe we agree that isn't desirable to handle the addition of all
> possible future link types in this draft since due to simply fact that
> different link types may require different compatibility considerations.

Right.

> At least defining the rules would provide a migration path if vendors and open
> source developers follow the rules.

Even if everyone on this list jumps on it tomorrow and checks their code to
ensure the follow this recommendation, there will still be networks out there
that happily run old equipment with old SW from vendors that don't even exist
anymore.

The side effect of recommending to ignore unknowns is creation of the impression
that we can rely on this behavior when defining new link types, while in fact we
can't. And if we can't rely on it, then why specify?

From your message to Dave:
> In a perfect world, an OSPF routing domain is under a single administrative
> authority and that authority should have some control over what is deployed.

This is a reasonable assumption. On the other hand, it seems we shouldn't assume
that the administrator of a moderate enterprise network knows all details of the
protocol machinery to the details of how version X of a specific implementations
handles this scenario. Since there would be no protocol-level safeguards against
newer implementations conflicting with legacy ones, it would look very shaky.

> If we can't agree that this is a good thing to do then I guess the default
> action is to maintain the status quo of leaving it undefined. At least
> initially, the concensus was to ignore the unknown link types.

It's a good thing we're having this discussion early in the process.

Alex

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 30 Mar 2005 11:28:29 +0000

> require different compatibility considerations.

the 'new' link types will fall into one of two categories:

. they will either affect the shortest-path tree for hop-by-hop
. or not (e.g. be only leaves or not do forwarding hop-by-hop traffic 
along those links [TE])

in case they do you must have a possiblity to understand what each 
router is doing in terms of topological capabilites and
based on that modify your SPF in the newer routers. It's a case of a 
chain of topologies
(means, topologies nested within each other, each additional capability 
defines a 'higher' level).
It has been proven that in such a scenario SPFs can be computed and the 
network works loop-free,
look up

*V. Fayet, D. A. Khotimsky, and T. Przygienda, \Hop-by-hop routing with 
node-dependent topology information," /in IEEE INFOCOM'99, Mar. 1999

The math is not for the faint of heart but you can just plug out the 
algorithm (which is a nested
Dijkstra with 2 or 3 ifs added).

If you add 'unknown' links (which means some routers understand them and 
use them for SPF hop-by-hop
and some don't), simple examples exist to prove that the network will 
loop easily (more rigorously, you
partially loose connectivity in the network)

    thanks

    -- tony

/*

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 30 Mar 2005 11:38:31 +0000

> . or not (e.g. be only leaves or not do forwarding hop-by-hop traffic 

hastily written, sorry,  'leafs', isn't it ?

>
> If you add 'unknown' links (which means some routers understand them 
> and use them for SPF hop-by-hop

here I implicitly ment, 'if you don't do anything else except normal 
Dijkstra', of course.

    -- tony