1. OSPF WG – IETF 70 - Vancouver OSPFv2 Multi-Instance draft-acee-ospf-multi-instance-00.txt Acee Lindem/Redback Networks Abhay Roy/Cisco Systems Sina Mirtorabi/Force10 Networks

2. OSPF WG – IETF 70 - Vancouver OSPFv2 Multi-Instance  OSPFv3 supports multiple instances with an “Instance ID” field in the header  Applications include:  Single link serving multiple communities of OSPF Routers  Single link belonging to two or more OSPF areas  OSPFv2 can do the same by using the first 8 bits of the AuType as “Instance ID”.  Maps to unknown AuType for routers not supporting it.

3. OSPF WG – IETF 70 - Vancouver OSPFv2 Multi-Instance Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPFv2 Packet Header

4. OSPF WG – IETF 70 - Vancouver Backward Compatibility  Backward Compatibility Issues with implementations logging errors  Can they cause more drastic issues?  Could do something more radical to “insulate” legacy implementations  Separate IP protocol  Separate Multicast IP Address  Authors don’t feel this is necessary - begs question as to why we don’t redesign the protocol  Implementations should already silently ignore unknown authentication type or, at least, rate limit the errors.

5. OSPF WG – IETF 70 - Vancouver OSPFv2/3 Transport-Instance draft-acee-ospf-transport-instance-00.txt Acee Lindem/Redback Networks Abhay Roy/Cisco Systems Sina Mirtorabi/Force10 Networks

6. OSPF WG – IETF 70 - Vancouver OSPFv2/3 Transport-Instance  OSPF protocol has the extensibility to carry arbitrary information:  OSPFv2 Opaque LSAs  OSPFv3 LSA function code  All this information can potentially contend with “routing” information  On the wire  In the router  This contention can impact timely route computation and network convergence  Goal is to send “non-routing” information in a separate OSPF instance

7. OSPF WG – IETF 70 - Vancouver Transport Instance Packets Differentiation  We can use Instance ID in OSPFv3  We can introduce Instance ID in OSPFv2

8. OSPF WG – IETF 70 - Vancouver Transport Instance Relationship to Normal OSPF Instance  Ships in the Night The Transport Instance has no relationship or dependency on any other OSPF instance.  Child Instance The Transport Instance has a child-parent relationship with a normal OSPF instance is dependent on a normal OSPF instance for topology information and assuring the "condition of reachability".

9. OSPF WG – IETF 70 - Vancouver Transport Instance - Ships in the Night  Additional overhead as topology information must be advertised to satisfy the condition of reachability  Prefix information can be suppressed  OSPFv2: Only router-LSAs, network-LSAs, and type 4 summary-LSA must be advertised. In the router-LSAs, the stub (type 3) links may be suppressed.  OSPFv3: Only router-LSAs, Network-LSAs, and inter-area-router-LSAs must be advertised.

10. OSPF WG – IETF 70 - Vancouver Transport Instance – Child Instance  Transport Instance will establish neighbor adjacencies just like a normal instance.  Topology information is not advertized.  Transport Instance will be dependent on its parent instance to verify the "condition of reachability" for any OSPF router.  Other optimizations are possible as well and are under discussions.

11. OSPF WG – IETF 70 - Vancouver Network Prioritization  Transport Instance will use an on-the-wire preference which is lower than normal OSPF instance don’t contend with “routing” instance  Use CS3 (011000) for Transport Instance  Normal OSPF instances uses CS6 (110000)  Applicable to both OSPFv2 and OSPFv3

12. OSPF WG – IETF 70 - Vancouver Transport Instance Information Encoding  TLV style encoding similar to Traffic Engineering Extensions  OSPFv2: Application specific information will be flooded in opaque LSAs  OSPFv3: Application specific information will be flooded in separate LSAs with separate LSA function codes.  OSPFv2 Application ID = Opaque LSA ID (8 bits)  OSPFv3 Application ID = LSA Function Code (13 bits)  8 bit Opaque LSA ID gives us 256 Applications (in last 9 years only 4 values have been used). Is that enough for future applications?

13. OSPF WG – IETF 70 - Vancouver Next Steps  How much innovation should be devoted to solving this problem?  Instances can be separated with Instance ID  Add Standardized packet deprioritization for transport instance  Add omission of prefix information from transport instance  Add sharing of topology information and possibly other state information between transport instance and corresponding standard OSPF instance - Implies congruency restrictions  Working Group Document?