[pim] BSR update

[Stig Venaas <stig.venaas at uninett.no>]

I gave an update on BSR this IETF. I went through changes we've made,
asked some questions, and got some input on what changes we should do
to the BSR draft. I would like to do those changes now, and then it can
hopefully go to last call.

I will now go through what happened in the PIM session (from my memory,
no notes), and would like some more input on certain things. I'm also
doing this to verify that those of you that were not at the meeting,
agrees to what choices was made.

The slides I presented can be found at
http://www3.ietf.org/proceedings/06mar/slides/pim-0.ppt

Slide 1, title page

Slide 2, just an overview

Slide 3, BSR priority

We have specified 64 as the default BSR priority. Received no
comments on that.

Slide 4, BSM Holdtimes

To get fast RP failover, it's useful to have very short holdtimes
for RPs, even shorter than BSM Period. However, the holdtimes used
in the BSMs must never be shorter than the period (apart from 0).
In new revision we're saying that BSMs MUST have holdtimes > period,
and SHOULD > 2.5 * period (to allow for some packet loss). We should
make it a bit clearer in the draft that the BSR may override the
holdtime from the RPs, and that it must enforce the above rules.

I got the impression that people agreed.

Slide 5, BSM Forwarding

New revision says that routers in C-BSRs state must forward
non-preferred BSMs from elected BSR. The reasons for this are
clear, and I believe everyone agrees.

New revision also says that P-BSRs should forward non-preferred BSMs.
This is not so clear, but there are some advantages, and no real
negative impacts.

As a comment, I asked what would happen if we generally forwarded all
BSMs passing RPF check. It was pointed out that some BSRs will send a
triggered BSM when receiving non-preferred.

Slide 6, Unicast BSMs

New revision says that they must be sent from the primary address,
and also only accepts them from the primary. I believe Dino said this
was problematic. But I must say now that I'm not sure why. Could you
clarify Dino? Or anyone else?

In particular I would like to enforce link-local addresses for IPv6.
I believe we can do that anyway, even if we don't require the primary
address for IPv4.

Latest revision also says that TTL MUST be 1. However, as was
discussed, a TTL of 255 might be better, see later discussion on
router alerts.

Slide 7, Triggered C-RP Advs

Previously we said that C-RPs SHOULD send triggered C-RP Advs when
new BSR is elected. We have now changed this to MUST. It's important
that the elected BSR gets a complete RP set ASAP. Does anyone think
a MUST here is problematic (it will require several implementations
to be updated), but is easy to implement).

Slide 8, Router Alert

New revision made some clarifications on IPv6 and Router Alerts. But
then I raised the question whether they are really needed. The
argument is as follows.

Router Alerts are used to secure unicast C-RP Advs and BSMs.

For C-RP Advs, we idea is that say a border router can spot the RA,
and check whether it's a C-RP Adv, and decide what to do with it.
I mentioned (I think), that instead the BSR could have restrictions
on what addresses to accept C-RP Advs from (e.g. accept only from
addresses in your domain).

For unicast BSMs the point is to make sure they don't travel
multiple hops. I said that the best way to do that, is to use a TTL
of 255 when sending, and check on receiving side that TTL is still
255. It also helps to require link-local addresses for IPv6.

As was pointed out by Dino, there are issues with backwards
compatibility and enforcing TTL of 255. For compatibility, routers
should probably accept unicast BSMs of TTL<255, but that would
reduce security. So what I propose for the new revision, is to say
that routers by default MUST only accept unicast BSMs with TTL of
255, but there should also be a way to configure a router to not
enforce this check for backwards compatibility. Not sure of the
exact phrasing. I could use some input from you folks here.

People in the room seemed to be happy to remove Router Alert if
we could have sufficient security without it. It adds little
security (if any), and requires extra work by border routers. Also,
Router Alert was not in RFC 2362, so backwards compatibility is not
an issue either (apart possibly from people having implemented
previous revisions of the new draft).

Any thoughts on this?

Slide 9, Editorial fixes

Not much to comment, see slide if interested

Slide 10, Fast BSR Re-election

This was discussed at previous IETF 64. Our proposal is to not add
anything for this in this draft. We believe it may be done purely
by having the C-BSRs dynamically adjust priorities to force
re-election. That is, by having some additional means (a protocol
between C-BSRs, using IGP and reachability or whatever), one can
solve this problem, while having non-C-BSR routers behave according
to this draft.

Slide 11, Next Steps

Plan is now to get a new draft out within 1-2 weeks, incorporating
the changes discussed above, and then we believe it's ready for
last call. Hence I would like your input on the above ASAP, so that
we hopefully will in 1-2 weeks have a draft that you are happy with.
I'm also happy to hear any other issues you might have with the
currrent draft.

Stig



_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim