Pekka Savola writes:

I have skipped the "Major comment" to which I think Toerless gave a
good response.

>More minor comments:
>--------------------
>
>Bidir PIM introduces the Bidir_Capable PIM-Hello option that MUST be
>included in all Hello messages from a Bidir-PIM capable router.  The
>Bidir_Capable option advertises the router's ability to participate in
>the Bidir-PIM protocol. The format of the Bidir_Capable option is
>described in section 3.7.
>
>==> HELLO?!?!!?!?  Do you mean that every router in a domain that is
>bidir-capable starts logging errors about every neighbor they have
>which is not bidir-capable?!??  Say goodbye to incremental deployment 
>and adding bidir capability on by default!

HIIIII!!!!! HOW ARE YOU?!?!?!?!?!
First of all there is no incremental deployment for BIDIR-PIM.  Mixing
BIDIR capable and legacy routers in a domain is a mis-config which the
option helps detect. Obviously if on a BIDIR capable router you have
BIDIR PIM disabled then you will not see such a message because you
have a non capable neighbour.
Now it is true that the option itself dates back to Dino's draft that
did specify incremental deployment. The main reason we cannot remove it
now is to keep existing code happy.

>The warning is should probably something that should be activated if a 
>group has been configured as bidir, but your neighbor isn't, or if you 
>try to use bidir forwarding algorithm towards the neighbor, and it 
>isn't bidir-capable.

There is currently no way of knowing what the group to RP / protocol
mapping is on a neighbouring PIM router. The assumption is that if the
neighbour is BIDIR capable then it has made the same interpretation of
the config / BSR advertisement.

>BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS'
>group `224.0.0.13'.
>
>==> IPv6 support, anyone?

Someone. Some of the v6 mods went into the current PIM-SM spec after I
pulled a lot of the text for Bidir. I guess we have missed some stuff
that changed since. We will go through PIM-SM to see what applies.

>...
>==> what is the BIDIR interdomain strategy?  There's no need for such, 
>I think, because it'll "just work the same way as PIM-SM" if you use 
>MSDP, but it would not hurt to spell it out.

It does not "just work". We scoped the mods at one point in time to
see what would be required. There are significant changes to make
source-only branches traverse a BIDIR domain.

>==> It would be worth stating (because it's not obvious) that the BSR 
>discovery works by the RP setting the bidir-capable bit in the 
>Encoded-Group Address (this isn't yet reflected in the bsr spec).

It was in the BIDIR spec but I pulled it out and handed the text over
to the BSR authors for inclusion in the next version of that spec.

>5.3.  Authentication Using IPsec
>
>The IPsec [5] transport mode using the Authentication Header (AH) is 
>the RECOMMENDED method to prevent the above attacks against BIDIR-PIM.
>
>It is RECOMMENDED that IPsec authentication be applied to all 
>BIDIR-PIM protocol messages.
>
>==> this is totally bogus recommendation, and luckily enough the 
>PIM-SM spec uses only MAY.  This would require manual key config on 
>the routers per interfaces, and is completely unrealistic.

I am sorry that this is so "totally bogus". I think this text was
again lifted from PIM-SM. We will update to match the current version.

Isidor


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