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

[Acee Lindem <[e-mail]>]

I'd agree if it hadn't been discussed at the last two IETFs with  
moderate support and virtually no opposition.
Thanks,
Acee
On Feb 27, 2009, at 1:48 PM, PAPADIMITRIOU Dimitri wrote:

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