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

From: Alex Zinin <[email-masked]>
Date: Tue, 15 Mar 2005 20:39:48 -0800

Folks-

 Here's the write-up of the comment I brought at the meeting in Minneapolis.

 What the draft says is (briefly):
   a) ignore unknown link-types (Section 2)
   b) now that we ignore unknowns, introduction of new link types is possible (Section 4)
   c) when introducing new link types, make sure routing loops are not created (Section 4)

 Noting that processing of the 4 current link types is part of the protocol's
 core functionality, that every OSPF router must be able to perform, we have the
 following scenarios where SPF meets an unknown link type:

   1) LSA creation malfunction at the originating router, before the LSA
      checksum is calculated.
   2) Memory corruption at the calculating router before LSA's checksum
      is rechecked.
   3) The originating router implements an extension of OSPF that introduces
      a new link-type that is not part of the basic OSPF functionality.
      
 In cases 1 and 2, silently ignoring the unknown link type is ill-advised, since
 it is extremely likely that routers will end up with inconsistent routing
 tables and loop traffic for a long time. At the very least, the router should
 "shout" very loudly. Whether the implementation should then (after shouting)
 ignore the unknown link and continue SPF calculation, stop the SPF calculation
 there, cancel SPF and retain old routes, or do anything else is not a clear
 choice and will depend on what the admin likes more--loops or blackholes. One
 could probably imagine different sorts of creative things (that I would
 personally not entertain) here.

 In case 3, something has obviously gone wrong. Changes affecting basic IP
 routing table calculation in OSPF were always introduced with a new Options
 bit. Introducing new link types that would affect routing table calculation
 without a new Option bit would be ill-advised again, since this would lead to
 long-term routing loops. Since such situation should not be legitimate,
 silently ignoring unknown link types here is also not a good idea.
 
 Given the above, I suggest that the related part of the spec is left intact and
 new link types are introduced with corresponding new Option bits.

 Comments are welcome.
 
-- 
Alex
http://www.psg.com/~zinin

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Mar 2005 01:48:44 -0800

Group, sorry about the backstep,

	But what is an unknown link-type? Doesn't
	it need a FORMAL definition/declaration
	and scope before it is dealt with?

	A) It is anything that is not one of the
	well-known types defined in the OSPF RFC.

	B) It is a value that is unknown to the
	nbr/peer assuming that the peer might have support
	for values beyond A.

	C) It is a value unknown to the current DR. This
	last one is due to the fact that the DR should
	always have the greatest amount of functionality.

	D) It is a value that should be unknown to 
	the routers in the area. Assume that the unknown
	is a wireless and the area only supports wired
	links.

	E) It is a local value "private" to the area and
	  should not be communcated outside of the area.
	  Assume that the area is wireless and is using
	  a private space for this link-type.
	  
	Thus, for compatibility, why doesn't the OSPF
	working group LOOK at the support for BGPs
	attribute definitions of Well-known, optional
	transitive, and optional non-transitive?

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