Routing Protocol Overloading Panel

1
Routing Protocol Overloading Panel

• Panelists
• Dave Meyer
• Pedro Roque Marques
• Gargi Nalawade
• Ron Bonica

2
Why are we here?

• Community is polarized over RP overload (BGP in
  particular)
• Camp 1
• MP-BGP framework is a useful tool to distribute
  info among INET routers
• Fair treatment of different AFI/SAFIs is an
  implementation problem
• We know how to do this, leave this to us
• Camp 2
• BGP is critical for the INET
• Overloading increases the risk of INET routing
  system failures

3
Why are we here? (contd.)

• We NEED to talk and get past it
• Walk out of the room with an understanding of the
  direction we need to move in
• Hopefully find a common ground

4
Rules of engagement

• People stand on different grounds--respect your
  opponents opinion
• Personality issues involved--leave them out of
  the room
• Dont just state your opinion--explain
• Lets be engineers

5
Next

• Panelist presentations (20m)--let people express
  their opinions
• Open discussion of the presentations (20m)
• Focused discussion of specific questions
• What belongs in a routing protocol
• What should we do with non-routing applications
  of the MP-BGP framework
• Wrap up

6
Panelist presentations
7
Open Mike

• Identify yourself
• 5 minutes max per person at a time
• Need to say more--requeue

8
Discussion notes

• Want/should
• Fate sharing,
• Overloading which part? Vendors or customers?
• Unicast or multiservices?
• Different boxes or same box? gt how?
• Same proto same resources ?Diff proto diff
  resources? NOT necessarily
• Features on top add bugs in basic BGP
• Can turn off a separate protocol
• If not BGP, then another protocol
• Size of the code matters! Exp( of lines)
• Dont want to pay for features not using
• Code reuse is possible across the protocols
• Other services may affect INET routing
  convergence
• General information distribution protocol
• Separate is important--can throw away
• It is about risk management

9
Targeted discussion

• What belongs in routing protocols
• What should we do with non-routing applications

10
What belongs in routing protocols?

• Data for discussion
• MP-BGP as a generic transport tool is out of
  scope for now
• INET BGP is within scope
• IGPs (OSPF, ISIS, RIP ) are in scope
• Main question whats ok to put on a RP?

11
From rtg-dir discussion

• RPs are designed with specific assumptions in
  mind
• amount of info, frequency of change,
  aggregateability
• influence protocol scalability characteristics
  (CPU util, BW, convergence, etc.)
• Routing HW and SW has been tuned over the years
  to work just right
• Putting arbitrary stuff may cause problems as
  fundamental assumptions may not hold true any
  more
• Appropriate in a RP
• info for RT calculation
• tags, admin and policy info
• security-related
• info closely related to routing, especially if
  synchronization with routing info is required

12
From rtg-dir discussion (cont.)

• For non-routing applications, the onus probandi
  lies with the proponents to show
• why a RP is appropriate
• why this wont break the protocol

13
Open Mike

• Identify yourself
• 5 minutes max per person at a time
• Need to say more--requeue

14
Discussion notes
15
What do we do with non-routing applications of
MP-BGP framework

• Data for discussion
• Assume that MP-BGP framework is attractive for
  non-routing apps
• Assume that BGP overloading concerns are valid
• How do we move forward?
• Some points for discussion...

16
From ops-dir and rtg-dir discussion

• If MP-BGP framework is considered to be a good
  fit
• Instantiate a separate protocol that would
  inherit MP-BGP FW, and
• work over a separate TCP port
• explicitly not interoperate with BGP
• would have its own name and life within the IETF
• What should we do meanwhile?
• Separate instance of MP-BGP over a separate TCP
  port?

17
Open Mike

• Identify yourself
• 5 minutes max per person at a time
• Need to say more--requeue