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

["PAPADIMITRIOU Dimitri" <[e-mail]>]

acee: 

> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]] 
> Sent: Tuesday, February 17, 2009 4:06 PM
> To: PAPADIMITRIOU Dimitri
> Cc: OSPF List
> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance
> 
> 
> 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.

The point here is that this notion of "instance ID" is not meant to
solve any "overload" problem it is primarily a separation of instances
for administrative and policy reasons. Any of them are instances
exchanges LSAs and Opaque LSAs.

In the present case, the problem - that i perfectly acknowledge - is
resulting from the dual use of Opaque LSAs wrt other LSA exchanges
whereas the instance ID does not assume such separation. 

Thanks,
-dimitri.
> 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
> >>
> 
>