[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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