BSR Spec Status

1
BSR Spec Status

• BSR Spec authors
• 03/06

2
Status

• ID refreshed (now rev-07)
• Resolved remaining issues we had on our list
• Updated to reflect WG input _at_IETF 64
• Default value for BSR Priority
• BSR enforces holdtime gt BS Period
• Are the changes made okay?
• All done?

3
BSR Priority

• At IETF 64 it was suggested to have a default BSR
  Priority
• We now say that a default of 64 should be used
• Chose 64 since 192 is default for RP priority,
  while for RP priority the lower is better
• Also, default value should be low so that
  accidentally configured C-BSRs can easily be
  prevented from interfering

4
BSM Holdtimes

• As discussed at 64, one should be able to use
  very short RP holdtimes between C-RPs and the BSR
• This holdtime need not be the same as in BSMs
• BSM holdtimes must be gt BS Period
• We now say that holdtimes in BSMs MUST be gt BS
  Period, and SHOULD be gt 2.5 BS Period
• 2.5 to allow for for packet loss
• We forgot to point out that holdtime of 0 is an
  exception, need to be fixed

5
BSM Forwarding

• Added forwarding of non-preferred BSMs from
  elected BSR by routers in C-BSR state
• This is important when elected BSRs priority is
  lowered so that another C-BSR will have highest
  priority
• Want to elect the new BSR without first timing
  out the old one
• Also added forwarding of non-preferred BSMs by
  P-BSR
• The benefit of this is not so clear
• Useful if some packet loss, but only helps if
  elected-BSR sends new BSM before P-BSRs BS timer
  expires (rand_override)

6
Unicast BSMs

• Specified that destination address must be
  neighbors primary address
• The one that PIM Hellos are sourced from
• Also restricted the rules for receiving unicast
  BSMs to require this
• For IPv6 this forces use of link-local address
• Also specified that ttl must be 1

7
Triggered C-RP Advs

• In previous version we said that C-RPs SHOULD
  after a short delay send C-RP Advs to a newly
  elected BSR
• We now changed this to MUST
• Necessary for newly elected BSR to have full
  knowledge of C-RPs

8
Router Alert

• Old text talked about IP Router Alert Option, now
  make it clear that also for IPv6
• Added IANA considerations for IPv6 Router Alert
  Option value
• IPv6 has different Router Alert Option values for
  different uses
• Currently 0 for MLD, 1 for RSVP etc.
• We believe we need a specific one for BSR
• Or are there other PIM related uses for Router
  Alert? Should BSR share RA value with something
  else?

9
Editorial Fixes

• Reference to hash function in PIM spec and note
  that it uses hash mask length
• Synched PS FSMs with text version
• Improved some language
• In particular, major changes to semantic
  fragmentation text
• Fixed some typos

10
Fast BSR Re-election

• This was brought up at IETF 64
• We have not tried to solve this, should it be
  part of the BSR draft?
• This could possibly be done as a separate
  protocol between C-BSRs without changing the BSR
  protocol itself
• Playing with priorities to force re-election
• It might be that minor changes to the BSR spec
  would make such an extension easier
• One option might be to look at such solution to
  see what minor changes (if any) would be needed
  to BSR and make those part of current BSR spec,
  but still have a separate document for the
  extension

11
Next Steps

• We have solved the issues were aware of
• Apart from the BSR re-election
• Does the WG believe we should do more changes to
  BSR?
• Are we done?
• Ready for last call?