Subject: RE: [pim] The BSR spec and maintaining group-to-RP mappings

From: Beau Williamson <[email-masked]>
Date: Mon, 01 Nov 2004 09:17:23 -0600

At 10/31/2004 08:30 PM, Christopher Thomas Brown wrote:
>3 Backward compatibility
>
>I don't think you can firmly make the claim that EW is backwards compatible.
>There is nothing that I recall in some of the older specs that requires
>a router to honor a holdtime of zero in a BSM as a request to remove
>the RP from that mapping. As has been said, older specs are ambiguous. Some
>implementations that do IW only remove from the RP set at a non-EBSR
>upon the implicit withdrawal and not on holdtime timeout.

Christopher,

Are you saying that in some implementations routers simply ignore the 
holdtime values in the RP-Set??  If so, I would maintain that this is a 
broken implementation and we shouldn't be concerned with this.

I thought the old spec was pretty clear that the routers would timeout a 
C-RP from the RP-Set when the holdtime went to zero.

Beau Williamson

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

---

From: Christopher Thomas Brown <[email-masked]>
Date: Mon, 01 Nov 2004 14:55:48 -0500

On Mon, 01 Nov 2004 09:17:23 CST
>C-RP from the RP-Set when the holdtime went to zero.

Beau,
I don't think its clear at all. I think its reasonable behavior to infer
but the spec does not clearly state that one should do this.

In  draft-ietf-pim-sm-bsr-00 in section 1.1 Overview of Bootstrap and
RP Discovery, it says,

>A Bootstrap message indicates liveness of the RPs included therein.  If
>an RP is included in the message, then it is tagged as `up' at the
>routers; RPs not included in the message are removed from the list
>of RPs over which the hash algorithm acts.

This seems to indicate to me that if an RP is included it should be
considered up. It doesn't say anything about paying attemtion to the
included holdtime. May one can infer this from the first sentence though.

In section 3.1 Sending Candidate-RP-Advertisements, is says,

>When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv
>to the BSR for each scope for which it is currently serving as an RP;
>the HoldTime in this C-RP-Adv message should be zero. The BSR will
>then immediately time out the C-RP and generate a new BSR message removing
>the shutdown RP from the RPset.

So, when the RP is shutdown I would expect to just not encounter it in
the BSM.

In section 3.2 Creating the RP-Set at the BSR it says,

>When the C-RP Expiry Timer expires, the C-RP is removed from the pool
>of available C-RPs.

Finally in section 3.4 Receiving and Using the RP-Set is says,

>If an RP is not in the new RP-Set, that RP is considered unreachable
>and the hash algorithm (see PIM-SM specification) is re-performed
>for each group with locally active state that previously hashed to
>that RP.

It doesn't say to pay attention to the holdtime.

So, no the old spec is not clear on what a PIM router should do with the
holdtime included in the BSM. It is silent in the subject as far as I
can tell. Maybe I missed a section.

So I wouldn't say an implementation that did not remove from its RP-Set
a C-RP included in a BSM with a zero holdtime is broken. Well, maybe I
would call it broken, but I wouldn't call it non-compliant. :)

That said, I like the explicit withdrawal approach better than the
implicit withdrawal method, even if it is not completely backwards
compatible with all existing implementations. From what I can gather
from various statements, I don't think we can get a good middle ground
that is completely interoperable, so we might as well choose the better
approach.

Chris

---

From: Stig Venaas <[email-masked]>
Date: Mon, 1 Nov 2004 22:32:23 +0100

On Sun, Oct 31, 2004 at 09:30:17PM -0500, Christopher Thomas Brown wrote:
> 
> Stig,
> I feel that the EW approach is better than the ambiguously defined
> approach that the current specification is.
> 
> However, I have some thoughts about things you bring up.
> 
> In section 2.1 you state:
> 
> >   IW: The router needs to wait for the entire Mapping record (G/mask
> >   and RP list) to be received before it purge mappings which have
> >   not been included this time. However, we think there is no way for
> >   a router to know that the entire mapping record has been
> >   received e.g. the last record in the fragment.
> 
> Is this true? It seems like one of the previous drafts had a solution for
> this problem. In a group range mapping there is a count of the RPs for the
> mapping (RP count) and a count of the RPs included in the current message
> (Frag RP count). Each fragment of the message carries a tag that indicates
> which instance of the BSR message it is. One knows when the entire mapping
> record has been received when one has received as many RPs for the group
> range as indicated by the RP count. One knows that a fragment has been
> lost when a new instance of the message is encountered.

My thinking here, is that you cannot notice missing fragments unless you
have a group range spanning multiple fragments. However, if you for IW
always include an empty group range in a BSM when removing the entire
group range, then I think you are right. Else you cannot distinguish
between a fragment being lost and a group range being removed. This can
be problematic in some cases. A newly elected BSR may need to keep a
copy of previously received BSM (to know that a group range is
disappearing when network is partitioned). Else the group range will
be kept until it expires.

> Now, I don't really like this approach but I think it does provide a way
> for a router to know that the entire mapping record has been received.
> Perhaps, I'm missing something here.
> 
> 
> 2.2 RP disappearing
> 
> For EW, I hope the 'trigger BSM' action is only for the affected group
> range and only the affected RP.

Yes, if the BSR only wants to remove an RP it should be enough to send
a BSM with just the one group range and the one RP with holdtime 0.

> 2.4 BSR disappearing
> 
> Is it really desirable to not have an RP set at all? Wouldn't using
> a previously available mapping be better than not having a mapping at all?
> Of course this should only occur if all of the CBSRs are down. How
> likely is it that all domain's CBSRs will be down? Is it worth trying
> to handle that or is going to an empty RPset OK.

Perhaps we shouldn't discuss it here since it's the same for both
approaches. I think that if a network is designed properly, there
should only be no CBSRs if the network is practically useless. If
e.g. all RPs are CBSRs then no CBSR means no RP and then it won't
help keeping the RPset. One reason for having a timeout, is that
it allows for moving from BSR to another "protocol". We could
possibly make this a special case and use another timeout than the
holdtime.

> 2.5 BSR being replaced
> 
> With EW, since the routers in the PIM domain do not change their RP sets
> in response to the elected BSR changing, it seems like an optimization if
> the newly elected BSR uses the RP set it had stored from the previous BSR
> to announce to the domain.

Yes. Also for IW this might be useful; see my 2.1 comment above.

> upon the implicit withdrawal and not on holdtime timeout.

The implementations I've checked honours the holdtime, but I agree it's
not clear that this should be done. Do you know for a fact that there
are some implementations not using the holdtime? In that case backwards
compatibility is difficult. We may also need to make that a third
category. Does anyone prefer that approach?

> * Transition
> 
> If consensus is reached on the EW approach, I think some of the suggested 
> IW behaviors should be documented as they help compatibility between
> EW and IW. A vendor that has implemented the IW approach with its current
> ambiguities can then implement the documented behaviors, if they have not
> already, and be reasonabilly sure that their IW implementation will
> interoperate with the EW approach.
> 
> Chris

Stig

---

From: Beau Williamson <[email-masked]>
Date: Mon, 01 Nov 2004 15:06:58 -0600

>that is completely interoperable, so we might as well choose the better

Well, it "has" been a long time since I went over the spec in great detail 
so I may have been reading more into the fact that there is a holdtime 
field for the RP in the BSM than was actually called out in the text.

So far, I'm leaning toward the EW method myself.  Unfortunately, I won't be 
at the DC IETF to discuss further.  Will continue to monitor the list for 
discussions.  One interesting scenario to the EW method previously raised 
was the total loss of all C-BSR's in the network.  If all routers ignore 
(i.e. don't implement) a holdtime timer for the RP entries in the BSR, and 
instead wait for the explicit withdrawal notification which never comes 
(because all BSR's are down) then all routers will continue with the last 
known RP Set.  Not sure this is the proper thing to do.  Need to think 
about this a bit more.

Beau

---

From: Nidhi Bhaskar <[email-masked]>
Date: Mon, 1 Nov 2004 21:21:58 -0800 (PST)

> a BSM with just the one group range and the one RP with holdtime 0.

This is a possible optimization, although it is not compatible with IW
implementations. Also, I have a preference for keeping things simple,
i.e. just generate a BSM vs. sending out selected mapping that have
timed out etc. Do you see some scenario where sending out the entire
mapping is problematic ? Are you concerend about too many messages ?
I think it is possible for the BSR to aggregate changes so that not
too many of these have to go out.

> Yes. Also for IW this might be useful; see my 2.1 comment above.

I'm less inclined to go this route. It seems better to let the new BSR
discover which RPs are still available rather than just refresh the
existing set and perhaps prolong the timeout for RPs that are now down
or partitioned ?

Thanks,
Nidhi.

---

From: Nidhi Bhaskar <[email-masked]>
Date: Mon, 1 Nov 2004 21:26:11 -0800 (PST)

Beau,

EW also uses the holdtime to expire RP entries. The difference between
IW and EW is how the BSR notifies the rest of the domain that an
RP/mapping is to be removed... When all BSRs die, the two approaches
behave the same way. I.e. the RP set on all routers in the domain
times out.

Thanks,
Nidhi.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 2 Nov 2004 07:57:56 +0100

> too many of these have to go out.

Good point. For compatibility with IR you would at least need to include
everything in that group range. It is simpler to always use the same
send algorithm though (sending everything).

> existing set and perhaps prolong the timeout for RPs that are now down

When switching BSRs I can think of two ways of making sure RPs that still
are alive and reachable are not lost in the process.

One way is the above. The other way is to have some special processing
on the routers when receiving an empty BSM. This might include cRPs
immediately sending advertisements and/or not remove entries when
the previous holdtime expires.

And yes, we have to balance this against keeping dead RPs too long.

I'm not sure myself which is best yet.

Stig

---

From: Christopher Thomas Brown <[email-masked]>
Date: Tue, 02 Nov 2004 12:44:18 -0500

On Tue, 02 Nov 2004 07:57:56 +0100
>send algorithm though (sending everything).

It is simpler but I am concerned about a situation in which a large
number of CRPs go down at once. If I get 10 CRPs withdrawing I will
send 10 complete BSMs rather quickly. Perhaps instead of trigerring
a BSM it would be better to lower the BSR timer to some small time
so that the periodic message is sent soon. This would be a simple
approach to aggregating the changes.

>I'm not sure myself which is best yet.

Well, one thing the new BSR could do it lower the holdtimes that it has
for the CRPS in the BSM to some smallish value. It should be a time
adequate enough to allow the CRPs to advertise themselves to the new BSR
and for the new BSR to then send out a new BSM. However, with this
approach two BSMs are sent out in a rather short period of time.

Chris