[pim] Initial pim 0.155
diff --git a/pimd/CAVEATS b/pimd/CAVEATS
new file mode 100644
index 0000000..7dc950f
--- /dev/null
+++ b/pimd/CAVEATS
@@ -0,0 +1,137 @@
+# $QuaggaId: $Format:%an, %ai, %h$ $
+
+C1 IGMPv3 backward compatibility with IGMPv1 and IGMPv2 is not
+ implemented. See RFC 3376, 7.3. Multicast Router Behavior. That's
+ because only Source-Specific Multicast is currently targeted.
+
+C2 IGMPv3 support for forwarding any-source groups is not
+ implemented. Traffic for groups in mode EXCLUDE {empty} won't be
+ forwarded. See RFC 3376, 6.3. Source-Specific Forwarding
+ Rules. That's because only Source-Specific Multicast is currently
+ targeted.
+
+C3 Load Splitting of IP Multicast Traffic over ECMP is not supported.
+ See also: RFC 2991
+ Multipath Issues in Unicast and Multicast Next-Hop Selection
+ http://www.rfc-editor.org/rfc/rfc2991.txt
+
+C4 IPSec AH authentication is not supported (RFC 4601:
+ 6.3. Authentication Using IPsec).
+
+C5 PIM support is limited to SSM mode as defined in section 4.8.2
+ (PIM-SSM-Only Routers) of RFC4601. That's because only
+ Source-Specific Multicast is currently targeted.
+
+C6 PIM implementation currently does not support IPv6. PIM-SSM
+ requires IGMPv3 for IPv4 and MLDv2 for IPv6. MLDv2 is currently
+ missing. See also CAVEAT C9.
+
+C7 (S,G) Assert state machine (RFC 4601, section 4.6.1) is not
+ implemented. See also TODO T6. See also CAVEAT C10.
+
+C8 It is not possible to disable join suppression in order to
+ explicitly track the join membership of individual downstream
+ routers.
+ - IGMPv3 Explicit Membership Tracking is not supported.
+ When explicit tracking is enabled on a router, the router can
+ individually track the Internet Group Management Protocol (IGMP)
+ membership state of all reporting hosts. This feature allows the
+ router to achieve minimal leave latencies when hosts leave a
+ multicast group or channel. Example:
+ conf t
+ interface eth0
+ ip igmp explicit-tracking
+
+C9 Only IPv4 Address Family (number=1) is supported in the PIM Address
+ Family field.
+ See also RFC 4601: 5.1. PIM Address Family
+ See also CAVEAT C6.
+ See also http://www.iana.org/assignments/address-family-numbers
+
+C10 FIXED Assert metric depends on metric_preference and
+ route_metric. Those parameters should be fetched from RIB
+ (zebra). See also pim_rpf.c, pim_rpf_update().
+
+C11 SSM Mapping is not supported
+
+ SSM Mapping Overview:
+
+ SSM mapping introduces a means for the last hop router to discover
+ sources sending to groups. When SSM mapping is configured, if a
+ router receives an IGMPv1 or IGMPv2 membership report for a
+ particular group G, the router translates this report into one or
+ more (S, G) channel memberships for the well-known sources
+ associated with this group.
+
+ When the router receives an IGMPv1 or IGMPv2 membership report for
+ a group G, the router uses SSM mapping to determine one or more
+ source IP addresses for the group G. SSM mapping then translates
+ the membership report as an IGMPv3 report INCLUDE (G, [S1, G],
+ [S2, G]...[Sn, G] and continues as if it had received an IGMPv3
+ report. The router then sends out PIM joins toward (S1, G) to (Sn,
+ G) and continues to be joined to these groups as long as it
+ continues to receive the IGMPv1 or IGMPv2 membership reports and
+ as long as the SSM mapping for the group remains the same. SSM
+ mapping, thus, enables you to leverage SSM for video delivery to
+ legacy STBs that do not support IGMPv3 or for applications that do
+ not take advantage of the IGMPv3 host stack.
+
+ SSM mapping enables the last hop router to determine the source
+ addresses either by a statically configured table on the router or
+ by consulting a DNS server. When the statically configured table
+ is changed, or when the DNS mapping changes, the router will leave
+ the current sources associated with the joined groups.
+
+C12 MRIB for incongruent unicast/multicast topologies is not supported.
+ RPF mechanism currently just looks up the information in the
+ unicast routing table.
+
+ See also:
+ RFC5110: 2.2.3. Issue: Overlapping Unicast/Multicast Topology
+
+ Sometimes, multicast RPF mechanisms first look up the multicast
+ routing table, or M-RIB ("topology database") with a longest
+ prefix match algorithm, and if they find any entry (including a
+ default route), that is used; if no match is found, the unicast
+ routing table is used instead.
+
+C13 Can't detect change of primary address before the actual change.
+ Possible approach is to craft old interface address into ip source
+ address by using raw ip socket.
+
+ See also:
+
+ RFC 4601: 4.3.1. Sending Hello Messages
+
+ Before an interface goes down or changes primary IP address, a
+ Hello message with a zero HoldTime should be sent immediately
+ (with the old IP address if the IP address changed).
+
+ See also pim_sock_delete().
+
+C14 Detection of interface primary address changes may fail when there
+ are multiple addresses.
+ See also TODO T32.
+
+C15 Changes in interface secondary address list are not immediately
+ detected.
+ See also TODO T31.
+
+C16 AMT Draft (mboned-auto-multicast) is not supported.
+ AMT = Automatic IP Multicast Without Explicit Tunnels
+
+ See also:
+
+ Draft
+ http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast
+ http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09
+
+ AMT gateway implementation for Linux
+ http://cs.utdallas.edu/amt/
+
+ AMT for Streaming (IPTV) on Global IP Multicast by Greg Shepherd (Cisco)
+ http://nznog.miniconf.org/nznog-2008-sysadmin-miniconf-greg-shepherd-iptv.pdf
+
+C17 SNMP / RFC 5060 (PIM MIB) is not supported.
+
+-x-