Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : instance

From: Erblichs <[email-masked]>
Date: Tue, 31 Jan 2006 17:08:44 -0800

Group,

	This is vastly more complicated, so these suggestions
	have been separated from my previous email.

	2.4  Explicit support for multiple instances per link

	"Support for multiple protocol instances on a link is accomplished via
   an "Instance ID" contained in the OSPF packet header and OSPF
   interface data structures.  Instance ID solely affects the reception
   of OSPF packets and applies to normal OSPF interfaces and virtual
   links."

	I like this for brevity, but ...

	Summary
	-------
	The major question is do we consider a instance equal
	to a underlying PDB?

	Verbose
	--------
	It is my understanding is if we want to separate adj's
	based on instance ID that is contained within OSPF
	control packets then we must:
	
	FYI: this list is not complete

	* For each set of links on different routers that have 
	matching Instance-ID, we must KEEP the adj's LSAs separate
	from other Instance-IDs LSAs.

	* We must be able to group one or more links with
	a area-id and though two area-ids may be equal, they must
	be kept separate because they below to different instances.

	* We must be able to group like Instance-ID areas with
	each other, which I will term a process.

	* Then each instance has one or more areas with one or
	more links, and that can be separately configured as
	a single independent OSPF process,

	* So, each process, must run separately to keep its LSAs
	separate and must each have full OSPF functionality.

	* This generates a separate routing domain per instance.

	THEN...... if this is true... My first ROUGH suggested
	change on this subject is...

	Support for multiple protocol instances within the OSPFv3
	protocol has a 2 part approach. One part is that the
	"Instance ID" is contained in the OSPFv3 packet header.
	The second part is that each Instance has one or more 
	links that can be shared by other instances. Each
	set of interfaces are grouped together into a area and
	the set of areas are grouped for normal OSPF functionality.

	Thus, the full set of LSAs recieved per instance are run
	within separate SPF algorithms and each has their own
	set of routing / forwarding tables.

	And each provider can be allocated an instance / separate
	OSPF process on a single router that will support the
	provider's requirements.

	Mitchell Erblich

---

From: Acee Lindem <[email-masked]>
Date: Tue, 31 Jan 2006 21:03:24 -0500

Hi Mitchell,
I'm afraid I don't agree with this suggestion either.  See inline.

>	The major question is do we consider a instance equal
I know for a fact that not all OSPF implementations have underlying PDBs 
:^).

>	* This generates a separate routing domain per instance.
Nope. A "protocol instance" is just that - a separate instance of OSPF 
with its own
separate set of protocol data structures, state machines, and processes. 
It usually but doesn't
necessarily imply a separate routing domain. I could add "Protocol 
Instance" to
section 1.2 if there is any confusion.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Tue, 31 Jan 2006 20:40:03 -0800

Acee,

	Yes, I was just using PDB as a 
	well-known reference global data struct
	that contains areas which contains links/interfaces,
	which contain neighbors.. I felt that I could use the name
	since the vendor published the name and decript 
	in a public doc.

	I don't expect it to be used in a IETF arch doc.
	
	So, WHERE does one find in this RFC, that an instance
	is succintly below what you just stated and not just s
	something specific to links / interfaces.

	I was trying to just re-word what was existing.

	But, I like your below statement , IMO, it still needs just a 
	bit more. That each instance is a fully functioning OSPF process
	that periodicly run a SPF algor. And that each LSDB within
	each instance can be completely different!

>a separate instance of OSPF
> with its own

	What about? An instance is a fully functioning OSPF protocol
	with its own separate set of protocol data structures (areas,
	interfaces, nbrs, LSDB, etc), state machines, and processes
	that include SPF calculations.

	Which what I read in this doc only refers to links and misses
	the mention of areas, or the groupings of areas, which has to
	be called something. I called it a process!!

	And this process, where do I find in this RFC reference to
	SPF calcs per instance?

	As to a separate routing domain, if diff instances do not exchange
	routing information LSAs, I don't see how they can be combined.
	And they don't DIRECTLY exchange because they have different
	instance-ids in their packets.

	Mitchell Erblich
	PS: I will send part 2 of this instance set of suggestions/
	    questions..
	And for people who can follow my logic, instance-ids can
	also split areas with two identical area-ids numbers but 
	different instances and different ABRs.
	------------