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

From: Acee Lindem <[email-masked]>
Date: Sat, 14 Feb 2009 16:43:50 -0500

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 15 Feb 2009 11:18:38 +0100

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Acee Lindem
> Sent: Saturday, February 14, 2009 10:44 PM
> To: OSPF List
> Subject: [OSPF] OSPF Multi-Instance and Transport Instance
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 17 Feb 2009 10:06:24 -0500

> 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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 18 Feb 2009 09:15:36 +0100

acee: 

> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Tuesday, February 17, 2009 4:06 PM
> To: PAPADIMITRIOU Dimitri
> Cc: OSPF List
> Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance
> 
> 

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.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 27 Feb 2009 11:58:44 -0500

Dimitri,
See inline.

> 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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 27 Feb 2009 12:49:42 -0500

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 <[email-masked]>
> Date: February 27, 2009 11:58:44 AM EST
> To: PAPADIMITRIOU Dimitri <[email-masked]>
> Cc: OSPF List <[email-masked]>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 27 Feb 2009 19:48:46 +0100

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. 

> 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:
> 
> 
> <[email-masked]>
> 				The first issue is: fixed 
> segmentation of resources between
> 
> 			instances
> 
> 				processing non-opaque and 
> opaque LSAs is less robust than a flexible
> 				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 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
> 				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
> 
> 				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
> 
> 				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
> 
> 	   instance packets, normal OSPF routing instances can 
> be given priority
> 	   packet priority.  However, implementation issues are 
> beyond the scope
> 	   of this document.
> 
> 	Thanks,
> 	Acee
> 
> 
> 
> 
> 
> 		Thanks,
> 		-dimitri.
> 
> 			Thanks,
> 			Acee
> 
> 
> 
> 
> 				-d.
> 
> 
> 
> 					From: 
> [email-masked] [mailto:[email-masked]] On
> 					Behalf Of Acee Lindem
> 					Sent: Saturday, 
> 					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
> 					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 
> 					topologies that I 
> believe clearly demonstrates the superiority of
> 					this solution. Hence, I

---

From: Acee Lindem <[email-masked]>
Date: Fri, 27 Feb 2009 14:05:36 -0500

I'd agree if it hadn't been discussed at the last two IETFs with  
moderate support and virtually no opposition.
Thanks,
Acee

---

From: David Ward <[email-masked]>
Date: Fri, 27 Feb 2009 14:44:04 -0600

I support this effort (and hope that OSPF catches up with the  
innovation and features in IS-IS.)

-DWard

On Feb 14, 2009, at 3:43 PM, Acee Lindem wrote:

> 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
> [email-masked]

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 27 Feb 2009 14:56:21 -0600

I also support this concept and the related work on a mechanism.  As for the specifics of the mechanism, I'll leave it to more brilliant OSPF'ers.

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Ward
Sent: Friday, February 27, 2009 2:44 PM
To: Acee Lindem
Cc: OSPF List
Subject: Re: [OSPF] OSPF Multi-Instance and Transport Instance

-DWard

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================