[pim] PIM refresh reduction discussion

For a complete view of the discussion which occurred on the pim-state
list, please go here:
http://www3.ietf.org/proceedings/07jul/slides/pim-2.txt

Suresh has provided a summary below. 

Refresh reduction or refresh elimination

*The consensus seemed to be to keep refreshes and use holdtime in the JP
PDU to eliminate them if someone wants it by setting the hold time to
max value. Otherwise, state would be refreshed every 30 minutes (or some
such large value).

Reliability

*Every JP PDU gets acked. A Hello option will help determine if all
routers on the LAN support JP ACK or not. If not, we revert back to
existing behavior.

How to achieve refresh reduction

*One of the goals was to make as minimal changes to PIM as possible.
Dino's suggestion was to use a new message type, say Join Ack, which
would look exactly like the JP Pdu. The upstream router that receives a
JP reflects back the same PDU to the downstream router by just changing
the PDU type. 
*To differentiate between successive state changes, we need to have a
sequence number. Where we differed: 

*Dino wanted to overload one of the reserved fields in the source
address field to use it as a sequence number per route. 
*Bob and I prefer that there be a seq num per PDU. The idea here was to
have a seq# TLV and just ack that in the JP Ack PDU. 

I think if we combine the two approaches, we get the following. See if
this is agreeable to you guys (I will use an example here):

oLet's say there are entries E1, E2, E3, E4 that have Joins scheduled to
be sent. 

oThe JP PDU will contain the entries E1 thru E4 as Joins. 

oA seq num TLV gets assigned to the PDU. Let's say the seq num is 1. All
entries get the seq number of the PDU they go in so that effectively,
each entry is associated with a seq num (what Dino wants).  

oThe JP PDU is sent out. A retransmission timer is started for the PDU
that starts off at a low value and backs off exponentially. 

oThe ACK is just a reflection of the JP PDU by changing the PDU type.
When the ACK is received, all entries associated with that PDU are
considered ACKed by the router that sent the JP PDU. For any other
downstream router, the seq number is meaningless. It processes the ACK
just as it processes a "See Join" or "See Prune" event. This gives the
other routers one more chance to see the PDU just in case they missed
the Join. 

oBefore the ACK is received, if the state changes for an entry, say E1
changes from a Join to Prune, E1 is added to a new PDU with seq #2.
Before PDU 2 gets sent out, if the state changes again, E1 simply gets
updated without having to change the seq number. So E1's seq number is
now 2.

oIf an ACK is received for seq #1, E2 thru E4 are considered ACKed, but
not E1, since E1 is not associated with seq #1 anymore. So the router
that processes the ACK does not really care about the contents of the JP
PDU, except the seq number and its notion of which entries correspond to
the seq number. Another way to look at it is to say that it goes through
each entry in the PDU and considers those entries acked whose seq number
match that of the PDU.

Other issues

*Both JP and JP Acks are multicast. This preserves Join Suppression.
There is still a problem where one downstream router Prunes a state and
the Upstream router Acks it back and this exchange (both the JP and the
JP ACK) is not seen by another downstream router that wants the state.
Now there is no traffic flowing on the LAN until this router refreshes
its state after a long period of time, if it decides to do so. The only
solution to this is to have explicit tracking. 

*There was also mention of ensuring bidirectional connectivity for
adjacencies. I think this should be addressed as well as part of
reliability. Once a JP Exchange occurs, if there is error on the link
leaving only one way connectivity where the Hellos sent by the Upstream
router are seen by the downstream router, but not vice-versa, data
forwarding simply stops, since the upstream router would have cleaned up
all downstream state while the downstream router assumes the upstream
router has all the state. This can be fixed by having a new 2Way Hello
option wherein each router adds its nbr IP in the TLV (OSPF style). This
is especially important when we are running PIM on overlay networks like
in L3VPN.

*Lastly, the need for L2 snooping devices to be able to request states
to build snooping state was mentioned. Modifying Hellos with GenId 0 to
force routers to refresh their state is a solution.

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