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

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

acee, 

since so far, I have seen two people discussing on this list on this
specific thread. i would have hoped much more debates before concluding
on the (bottomline) approach to follow.

thanks, 
-d. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Acee Lindem
> Sent: Friday, February 27, 2009 6:50 PM
> To: OSPF List
> Subject: [OSPF] Fwd: OSPF Multi-Instance and Transport Instance
> 
> I believe we are now ready to take this AD sponsored work on 
> and make these OSPF WG documents. 
> Thanks,
> Acee 
> 
> 
> Begin forwarded message:
> 
> 
> 	From: Acee Lindem <[e-mail]>
> 	Date: February 27, 2009 11:58:44 AM EST
> 	To: PAPADIMITRIOU Dimitri 
> <[e-mail]>
> 	Cc: OSPF List <[e-mail]>
> 	Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance
> 
> 	Dimitri,
> 	See inline.
> 	On Feb 18, 2009, at 3:15 AM, PAPADIMITRIOU Dimitri wrote:
> 
> 
> 		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.
> 
> 
> 	I believe the OSPF instance provide a natural boundary 
> to address this
> 	problem better than mechanisms within a protocol. Refer 
> to section 2.4.
> 
> 	2.4.  Network Prioritization
> 
> 	   While OSPFv2 (section 4.3 in [OSPFV2]) are normally 
> sent with IP
> 	   precedence Internetwork Control, any packets sent by 
> a transport
> 	   instance will be sent with IP precedence Flash 
> (B'011').  This is
> 	   only appropriate given that this is a pretty flashy 
> mechanism.
> 
> 	   Similarly, OSPFv3 transport instance packets will be 
> sent with the
> 	   traffic class mapped to flash (B'011') as specified 
> in ([OSPFV3].
> 
> 	   By setting the IP/IPv6 precedence differently for 
> OSPF transport
> 	   instance packets, normal OSPF routing instances can 
> be given priority
> 	   during both packet transmission and reception.  In 
> fact, Some router
> 	   implemenations map the IP precedence directly to 
> their internal
> 	   packet priority.  However, implementation issues are 
> beyond the scope
> 	   of this document.
> 
> 	Thanks,
> 	Acee
> 
> 
> 
> 
> 
> 		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
> 
> 
> 
> 
> 
> 	_______________________________________________
> 	OSPF mailing list
> 	[e-mail]
> 	https://www.ietf.org/mailman/listinfo/ospf
> 
> 
>