Re: [OSPF] OSPF Multi-Instance and Transport Instance

pls, re-read your meeting minutes. 

The first issue is: fixed segmentation of resources between instances
processing non-opaque and opaque LSAs is less robust than a flexible
sharing of these resources assuming events triggering opaque and
non-opaque LSAs (used indirectly by some application) are independent.
The assumption of correlation (opaque LSAs directly processed by OSPF)
is left possible by RFC 2740. Nevertheless, this draft does not isolate
the "IP Routing instance" from the latter LSAs.

The second issue is: i) the proposal moves from multiplexed exchanges to
serialized exchanges of LS PDUs between peering instances of opaques and
non-opaque LSAs, ii) the messaging between different instances still
share the same links and header processing (note: by definition
instances are "co-located") but are under the control of different
instances thus requiring further prioritization at the sender side.
Thus, the current proposal further constraints the sender's instances to
expectedly prevent overloading the receiver. This is made possible by
putting down to the OSPF header (instead of the LSA header) the
information with which prioritization at the sender would be possible.
Nevertheless, is that not strictly equivalent to prioritize on the LSA
header when the instances are common i.e. the draft adds an identifier
because it puts processing down the OSPF header. The result is not
different from what would be possible using the "Opaque Type" (in
combination with the LS Type) since it is only for a sub-class of Opaque
LSA (those that are not directly processed by OSPF) that the issue of
overloading expectedly arises.

-d.

> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On 
> Behalf Of Acee Lindem
> Sent: Saturday, February 14, 2009 10:44 PM
> To: OSPF List
> Subject: [OSPF] OSPF Multi-Instance and Transport Instance
> 
> In Minneapolis, there was some interest in making these WG group  
> documents. Additionally, the AD have sponsored this activity given  
> that a solution is being actively pursued in the ISIS WG (though  
> significantly less powerful).
> 
> There was one dissenting comment that one could achieve the same  
> results with a single instance given sufficient invention (aka, the  
> "even pigs can fly" argument). I've added text to the transport  
> instance draft as well as mechanisms and text enabling sparse  
> topologies that I believe clearly demonstrates the superiority of  
> this solution. Hence, I like to now ask if there is any further  
> reason not to make these WG documents?
> 
> Here are the current versions:
> 
> http://www.ietf.org/internet-drafts/draft-acee-ospf-multi- 
> instance-02.txt
> http://www.ietf.org/internet-drafts/draft-acee-ospf-transport- 
> instance-02.txt
> 
> Thanks,
> Acee 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> 