Embed Size (px)
Citation preview
OSPF WG – IETF 70 - Vancouver
OSPFv2 Multi-Instance
draft-acee-ospf-multi-instance-00.txt
Acee Lindem/Redback NetworksAbhay 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
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
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?
