[pim] draft-ietf-pim-sm-bsr-04.txt

[Alexander Gall <[e-mail]>]

Hello all

A new version of the BSR draft is now available.  Nidhi Bhaskar, Stig
Venaas and myself have taken over from the previous authors.

Here is a short summary of the changes from -03 to -04.

- Made spec PIM generic
	That is, for RP-based PIM protocols (PIM-SM, Bi-dir PIM)
	New title etc
	Removed text about selection of a particular RP for a group
	range (must be covered in the spec of the routing protocol)

- Added section on Bi-dir PIM and defined Bi-dir bit for group ranges
	This is more or less what was in Bi-dir spec a few revs ago

- Using holdtime for maintaining RP-set at all routers (not just BSR)
	Timer per group-to-RP mapping
	Group-to-RP mappings are removed only when holdtime expires
		Holdtime of 0 means remove immediately
	Need to regularly receive BSMs to keep mappings in RP-set
	Trying to make sure RP info doesn't disappear when electing new BSR
		All routers keeping copy of last BSM (not just DRs)
			When BS Timer expires, refresh Holdtime once, then
				remove BSM copy.

- Holdtime is used differently at BSR 
	Timer per candidate group-to-RP mapping
	May receive different mappings in different C-RP-Adv

- Some attempts at clarification, some text rewritten, some new
  terminology 

- Fixed misc typos

Quite a large number of issues with the previous version have been
raised on the list in the past months.  Many of them have not yet been
addressed in -04.  Here are some explanations for the choices we've
made. 

We have decided that the entire scoping issue is too involved (and
probably controversial) to be addressed in this version of the draft.
All scoping-related text has been left unchanged (which might make the
document inconsistent in that respect).  We will post the issues and
possible solutions we came up with to the list.  I'll also present
them in San Diego.  We are considering whether the scoping part can be
moved to a separate draft.

While working on the other issues, we realized that a clarification of
how routers manage their RP-sets was needed.  The previous spec
(RFC2362) made it quite clear that the holdtime was only used at the
BSR, even though it is included in bootstrap messages.  The new spec
up to -03 was a bit unclear in this respect, which is reflected in the
fact that some of the existing implementations use the holdtime only
at the BSR while others use it at non-BSR routers as well.

We have chosen to clarify that the holdtime must be used by all
routers to time out their group-to-RP mapping information.  This is
the major change in -04.  We would like to see if this approach is
accepted by the WG before checking in detail how the issues raised
before apply to it.

Some of the drawbacks we identified in the previous (2362) spec:

- State at routers can only be removed explicitely through BSMs

- Routers may lose part of their RP-set during election of a new BSR

- Difficult to detect a withdrawn group-range in some cases, BSR needs
  to synthesize BSMs with RP count zero

To overcome this, we have introduced the group-to-RP mapping as the
basic unit of information distributed by BSR (the definition of the
mapping has been extended from the one in -03).  Each mapping is
managed independently at the BSR and within the RP-set held by a
non-BSR router.  In particular, all state is now allowed to expire.
The BSR is essentially viewed as a "proxy" for C-RP-Advs and does not
need to perform any special action on behalf of the C-RPs.

We have added a new mechanism to make the system more resilient
against the fail-over between C-BSRs.  This is done by refreshing the
RP-set with the last received BSM when the BS Timer expires, which
should prevent the RP-set from expiring during election of the new
BSR, at least with reasonable values for the timers involved.  

--
Alex


_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim