1 / 11

BSR Spec Status

BSR Spec Status. BSR Spec authors 03/06. Status. ID refreshed (now rev-07) Resolved remaining issues we had on our list Updated to reflect WG input @IETF 64 Default value for BSR Priority BSR enforces holdtime > BS Period Are the changes made okay? All done?. BSR Priority.

aricin
Download Presentation

BSR Spec Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 @IETF 64 • Default value for BSR Priority • BSR enforces holdtime > 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 > BS Period • We now say that holdtimes in BSMs MUST be > BS Period, and SHOULD be > 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 BSR’s 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-BSR’s BS timer expires (rand_override)

  6. Unicast BSMs • Specified that destination address must be neighbor’s primary address • The one that PIM Hello’s 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 we’re 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?

More Related