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

From: Acee Lindem <[email-masked]>
Date: Thu, 9 Feb 2006 14:14:51 -0500

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