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

[Acee Lindem <[e-mail]>]

On Feb 15, 2009, at 5:18 AM, PAPADIMITRIOU Dimitri wrote:

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

Section 2.4 addresses IP/IPv6 packet prioritization and many (if not  
most) commercial routers use the packet precedence for internal  
prioritization. What more would be required? We could state that the  
precedence MAY also used for internal prioritization. However, we  
want to steer clear of implying a specific implementation.

Thanks,
Acee


>
> -d.
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>>