Subject: RE: [pim] Re: [Pim-state] pim-state mailing list shutting down

From: "Bandi Sarveshwar-G19441" <[email-masked]>
Date: Tue, 15 Nov 2005 12:58:05 +0800

My opinion too is to standardize PIMv2 as it exists today. JP-Ack
proposal could probably be considered as an extension later. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dino Farinacci
> Sent: Sunday, November 13, 2005 3:06 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [pim] Re: [Pim-state] pim-state mailing list shutting down
> 
> >> The pim-state mailing list was created for a small design team to 
> >> work on pim state refresh reductions. That team now needs 
> more input 
> >> from the PIM working group and L3VPN working group. To 
> encourage this 
> >> and allow others to stay in touch with the continued 
> effort, I have 
> >> decided to close down the pim-state mailing list and move 
> all of its 
> >> traffic over to the main [email-masked] list.
> 
>     Enclosed is the current thinking for the JP-Ack proposal 
> I summarized
>     at the PIM working group meeting.
> 
>     And I would like the working group to judge if this 
> should be an extension
>     to PIMv2 or an addition to PIMv3. I think the later so we 
> can get PIMv2
>     to Draft Standard.
> 
> Dino
> 
> --------------------------------------------------------------
> -----------------
> 
> 
>       JP-Ack Proposal (for reducing periodic JP messages in PIM)
>       ----------------------------------------------------------
> 
> [1] Introduce a JP-Ack PIM message. It is always multicasted 
> to 224.0.0.13 or
>     ff02::d. Contains same format as JP message.
> 
> [2] JP-Ack-Capable routers indicate they can send and receive 
> JP-Acks by
>     including JP-Ack Hello Option in Hello messages.
> 
> [3] What JP senders do:
> 
>     o When they send JPs to an upstream router which is 
> JP-Ack-Capable, they
>       set a Ack-Received flag to FALSE for each route that is 
> inserted in the 
>       join- or prune-list portion of the JP.
> 
>     o Then start a 1 second jittered retransmission timer. 
> Retransmission 
>       occur until the upstream router disappears from the 
> neighbor cache. The 
>       retransmission timer can optionally be altered but 
> cannot exceed 60
>       seconds (the default periodic interval).
> 
>     o When the timer expires, build JP for all routes with 
> the Ack-Received
>       flag set to FALSE.
> 
>     o When the 1 minute periodic JP interval expires, only 
> include routes
>       which have the Ack-Received flag set to FALSE.
> 
> [4] What JP-Ack senders do:
> 
>     o After a received JP is processed, modify the type field 
> to turn the
>       message into a JP-Ack. No other fields change in the 
> PIM payload message
>       other than the type and checksum fields.
> 
>     o For each route in the JP, set Ack-Sent flag to TRUE. 
> This signifies that
>       any oif-list entry will not time out regardless of the 
> holdtime value
>       sent in the JP. This allows the JP transmitter to not 
> worry about 
>       refreshing the route.
>  
>     o If the PIM checksum check fails, drop the JP message 
> and do not return
>       a JP-Ack.
> 
> [5] What do receivers of JP-Acks do:
> 
>     o Regardless if you sent an JP or not, for each entry in 
> the JP which
>       you have state for, set the Ack-Received flag to TRUE 
> so at the next 
>       periodic interval, the route is not included in a 
> periodic JP. During 
>       steady-state, there will be no routes with Ack-Received 
> equal to FALSE, 
>       so no JPs are sent.
> 
> [6] What about triggered JPs?
> 
>     o When new state is created, the Ack-Received flag is set 
> to FALSE, so a 
>       JP message is triggered. And will later be JP-Ack'ed.
> 
>     o When an RPF change occurs, for each route that is 
> affected, set the
>       Ack-Received flag to FALSE and trigger a JP.
> 
> [7] What happens when a joiner goes down?
> 
>     o When a single joiner goes down, you want the upstream 
> router to start
>       timing out routes.
> 
>     o When there is more than one joiner, and a joiner goes 
> down, you want to
>       make sure timeout-suppression still occurs.
> 
>     o Whenever a PIM neighbor goes down, upstream routers 
> will set the Ack-Sent
>       flag to FALSE which will cause timeout processing to start.
> 
>     o Whenever a PIM neighbor goes down, downstream routers 
> will set the
>       Ack-Received flag to FALSE which will cause periodic 
> processing to 
>       start. Which means when the 1 minute periodic interval 
> expires, JPs 
>       will be sent. This will scatter the JPs across a 
> jittered 1 minute
>       periodic interval.
> 
>     o If, from an upstream router's perspective, a downstream 
> neighbor times 
>       out but the downstream neighbor thinks the upstream 
> router is alive
>       (an issue with one-way connectivity), the upstream router should
>       send a triggered Hello with a new GENID value. This 
> will cause the
>       downstream router to detect an adjacency change. In 
> this case, the
>       downstream router will send a full set of JPs. This is 
> necessary so
>       upstream router does not time out oifs when the 
> downstream neighbor
>       thinks it doesn't need to send a JP message.
> 
>       It is important to note that the Hello be unicast with 
> a GENID value of
>       0. The Hello is unicast so other neighbors on the LAN 
> don't get involved
>       in sending JPs. The reason for a GENID value of 0, is 
> so the downstream
>       router can get solicited to build a full set of JP 
> messages. When the
>       next hello interval expires, the upstream router will 
> transmit a Hello
>       with a GENID equal to it's last value. This way other 
> neighbors don't
>       think there is a neighbor up/down transition.
> 
> [8] Changing an entry for join-state to prune-state:
> 
>     o When a prune-entry (negative cache state entry) has an 
> empty oif-list
>       which goes to non-empty, a Join will be triggered, in 
> this case the
>       Ack-Received flag is set to FALSE so the Join can be 
> sent reliably and
>       the now join-entry can be suppressed from future JPs.
> 
>     o When a join-entry which has an non-empty oif-list goes 
> to empty, a Prune
>       will be triggered, in this case the Ack-Received flag 
> is set to FALSE so
>       the Prune can be sent reliably and the now prune-entry 
> can be suppressed
>       from future JPs.
> 
>     o In the case an entry changes from a join-entry to a 
> prune-entry or
>       vice versa before an JP-Ack is received for the 
> previous state should
>       cause no problem since the JP sender only cares about 
> the latest state
>       it has. If a JP-Ack is returned for a entry that is in 
> the Join-list
>       but the cached state is a prune-entry (or in the 
> Prune-list for a
>       cached join-entry), the Ack-Received flag is not 
> touched (this is an old
>       Ack).
> 
>     o In the case a JP sequence (3 separate JP messages) 
> consists of a {Join, 
>       Prune, Join} for the same multicast route, if the an 
> JP-Ack for the first
>       JP-Join message is received by the downstream router 
> after it had
>       sent the third JP Join message, the downstream router 
> would not ever
>       retransmit a JP-Join message. In the case, the third 
> JP-Join message
>       was lost, the upstream router would have prune-state 
> where the downstream
>       router would have join-state. To avoid this situation, 
> an implementation
>       can delay sending the third JP-Join awaiting the JP-Ack 
> for the first 
>       JP-Join.
> 
>       The same situation occurs with a JP sequence of {Prune, 
> Join, Prune} for
>       the same multicast route. In this case, the upstream 
> router keeps 
>       forwarding data since it has join-state but the 
> downstream router has
>       prune-state.
> 
>       This situation should be rare since the rate of a 
> multicast route flap
>       would most likely be greater than a JP retransmission interval.
> 
> [9] Duplicate JP-Acks and JPs:
> 
>     o If a JP-Ack is received for a set of routes which 
> already have the
>       Ack-Received flag set to TRUE, no action is taken. This 
> is known as
>       a duplicate JP-Ack. This is the case where a router on 
> a multi-access 
>       LAN either didn't received the JP-Ack or it's JP was 
> not received by the
>       upstream router. So a retransmission of either had occurred.
> 
>     o If a JP-Ack is received for a route where the JP-Ack 
> has a prune-list
>       entry for the route but the route has join-state 
> (oif-list not empty),
>       then the Ack-Received flag should be set to FALSE so 
> retransmission
>       of a Join can happen. The converse is true if the 
> JP-Ack had a join-list
>       entry for a route in prune-state (oif-list that is 
> empty). This can
>       happen when a route transition from join-state to 
> prune-state (or vice-
>       versa) occurs and either the JPs or the JP-Acks were reordered.
> 
>     o If an upstream router receives a JP for a set of routes 
> which already
>       have the Ack-Sent flag set to TRUE, a JP-Ack should be 
> returned. This
>       is a case where a downstream router didn't not receive 
> the previously
>       sent JP-Ack or has triggered a JP it wants an JP-Ack for.
> 
> [10] RPF Changes:
> 
>     o When an RPF neighbor change occurs, a JP with join-list 
> entries is sent
>       to the newly determined RPF neighbor. It is optional to 
> also send a
>       JP with prune-list entries to the previous RPF 
> neighbor. In the later
>       case, while the JP-prune-list sender is waiting for a 
> JP-Ack from the
>       previous RPF neighbor, other RPF change could occur. An 
> implementation 
>       has to remember the previous RPF neighbors so it can 
> make sure the 
>       prune-list JP gets reliably sent.
> 
> [11] Dealing with Prune-Override on multi-access LANs:
> 
>     o On multi-access LAN, a downstream router that is 
> pruning for a multicast
>       route will multicast the JP message on the LAN. The 
> upstream router
>       will delay removing the oif from the multicast route 
> waiting for other
>       downstream routers to override the Prune with a Join 
> message. To make
>       this sequence reliable would require a total of 4 
> messages. The initial
>       JP-Prune triggers the sequence from the downstream 
> router, the upstream
>       router responds with a JP-Ack multicast to the LAN, 
> then an overriding
>       router (if one exists) will send a multicast JP-Join 
> which causes the
>       upstream router to return a JP-Ack for the Join.
> 
>     o The reliability problem occurs because an overriding 
> router may not see
>       the triggering JP-Prune or the upstream router's 
> JP-Ack. Even though 
>       the overriding router has 2 chances to send the Join to 
> override the
>       Prune, both messages could be lost during a congestion 
> period. Since
>       the join-state in the downstream router had previously 
> been acknowledged
>       by the upstream router, the downstream router would 
> never send the Join
>       again.
> 
>     o There are two solutions to the problem, (1) Upstream Router Join
>       Solicitation or (2) Explicit Tracking.
> 
>     o Upstream Router Join Solicitation is when the upstream 
> router will
>       forward the received JP-Prune back out the multi-access 
> LAN and require
>       JP-Acks from each downstream neighbor regardless if 
> they want to Prune-
>       override or not. This assures that all neighbors have 
> the chance to
>       send their Joins. In this case, not all neighbors have 
> to send Joins.
>       The Join suppression mechanism from the base PIM spec 
> can be used.
> 
>     o Explicit Tracking is when the upstream router keeps 
> track of each
>       neighbor who has Joined for a particular multicast 
> route. So when a 
>       JP-Prune is sent to the upstream router, it knows when 
> the last Joiner
>       stops joining. In this case, only the JP-Prune needs to 
> be JP-Acked
>       and the oif is removed from the multicast route only 
> when the last 
>       Joiner sends a Prune. This will trade-off memory for 
> less messages on
>       the LAN.
> 
>     o We propose when Explicit Tracking is used, that each 
> router on the LAN
>       advertise the fact in a PIM Hello option. This allows 
> the downstream
>       routers to tell the upstream router not to expect Prune-override
>       messages. Also it tells the upstream router that the 
> downstream routers
>       will not be doing Join Suppression (each downstream 
> router must send
>       Joins so the upstream router can explicitly track each one).
> 
> --------------------------------------------------------------
> -----------------
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim
> 

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 14 Nov 2005 22:31:18 -0800

>> proposal could probably be considered as an extension later. 

    It depends on how extensive the basic PIM machinery changes.

Dino