OSPFv2 Multi-Instance draft-acee-ospf-multi-instance-00.txt

1
OSPFv2 Multi-Instance draft-acee-ospf-multi-insta
nce-00.txt

• Acee Lindem/Redback Networks
• Abhay Roy/Cisco Systems
• Sina Mirtorabi/Force10 Networks

2
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
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
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 dont feel this is necessary - begs
  question as to why we dont redesign the protocol
  
• Implementations should already silently ignore
  unknown authentication type or, at least, rate
  limit the errors.

5
OSPFv2/3 Transport-Instance draft-acee-ospf-trans
port-instance-00.txt

• Acee Lindem/Redback Networks
• Abhay Roy/Cisco Systems
• Sina Mirtorabi/Force10 Networks

6
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
Transport Instance Packets Differentiation

• We can use Instance ID in OSPFv3
• We can introduce Instance ID in OSPFv2

8
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
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
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
Network Prioritization

• Transport Instance will use an on-the-wire
  preference which is lower than normal OSPF
  instance
• dont contend with routing instance
• Use CS3 (011000) for Transport Instance
• Normal OSPF instances uses CS6 (110000)
• Applicable to both OSPFv2 and OSPFv3

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