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

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



Hi Mitchell,

Erblichs wrote:

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
separate set of protocol data structures, state machines, and processes.



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.


I'll add a definition to the terminolgy section.

	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.


While the circumstances are unique, you could have multiple OSPF instances in the same
routing domain (in other words they share a common IP address space and operate
on the same routing table).


Thanks,
Acee

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.
------------



Acee Lindem wrote:


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

Erblichs wrote:



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?




I know for a fact that not all OSPF implementations have underlying PDBs
:^).



     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.




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



     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