Presentation on theme: "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."— Presentation transcript:
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
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.
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.
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
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
OSPF WG – IETF 70 - Vancouver Transport Instance Packets Differentiation We can use Instance ID in OSPFv3 We can introduce Instance ID in OSPFv2
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".
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.
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.
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
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?
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?