Subject: [pim] register messages vs. the SPT

From: Rahul Bahadur <[email-masked]>
Date: 05 Feb 2004 12:14:49 -0800

Hello,

I have a question about register-encapsulation vs. the SPT. Assume the
following topology:

source - DR - PIMrtr - RP -------- receiver(s)?

The source is constantly sending traffic.

Initially the DR has no state and sends a register packet to the RP that
replies with a register-stop. The DR stops encapsulation starts the 
register-suppression timer.

Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G)
join from PIMrtr. The DR starts forwarding data natively.

When the register-suppression timer expires, should encapsulation
re-start?

Thanks,
Rahul

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

---

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Thu, 5 Feb 2004 14:40:24 -0600

No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data.

--
Sonum

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahul Bahadur
Sent: Thursday, February 05, 2004 12:15 PM
To: [email-masked]
Subject: [pim] register messages vs. the SPT

Hello,

I have a question about register-encapsulation vs. the SPT. Assume the following topology:

Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the 
register-suppression timer.

Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively.

When the register-suppression timer expires, should encapsulation re-start?

Thanks,
Rahul

---

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Fri, 6 Feb 2004 18:22:29 -0600

> So, I submit to you that sending a single register to the RP 
> and having  
> the
> RP join to the SPT (X-line) would be "good enough".  Not 
> according to  
> the
> spec, but definitely "good enough".
> 
> Arguments about how this decision will result in lost packets to the  
> receiver
> are valid, but considering how horrible PIM ASM is at delivering all  
> the packets
> anyway -- who cares.

From what I understand, you are suggesting that Sender's DR should be sending just one Null Register packet and no further Null/Encap Registers at all. This would be ok with the receivers who are ready to miss few initial packets (for the time duration of getting native path established - (S,G) Join reaching Sender's DR from the RP). Moreover, if this Null Register packet gets dropped, then RP will not be aware of the new source at all. 

What is the gain in doing this ? I believe that sending Registers encapsulating data is worth the effort and overhead for minimizing lost packets for the receivers.

> NOTE, the spec specifies that NULL registers are sent as a "probe"
> and that if a register-stop isn't received that an encapsulated
> register is sent.  In practice this "should" mean that the
> encapsulated register should never get sent.  It isn't clear to
> me why an RP that receives a NULL register but doesn't respond
> with a register stop will do any better with an encapsulated
> register, but I suppose an implementation might drop NULL registers
> (because of CRC errors or whatever) and not drop encaped registers.

That's true. If RP is not responding to Register-Stop, then it is highly likely that it will not respond to encapsulated register also. Only advantage in doing this could be that receivers can get decapsulated data (that also is based on the assumption that native tree is broken).

--
Sonum

> From: John Zwiebel [mailto:[email-masked]] 
> Sent: Thursday, February 05, 2004 3:40 PM
> To: Mathur Sonum-CSM109
> Cc: John Zwiebel; 'Rahul Bahadur'; [email-masked]
> Subject: Re: [pim] register messages vs. the SPT
> 
> 
> 
> 
> On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote:
> 
> >
> > No, after register-suppression timer expires, DR should send Null
> > Register packet to the RP (it is to inform RP that Sender is till  
> > active and to refresh the (S,G) state on RP without sending data).  
> > Moreover, SPT should not have been built as there are no 
> receivers so  
> > far (hope that's what you meant). Even if the receiver had joined,  
> > then also DR should just send Null Register packet to RP after the  
> > reg-suppression timer expires. In that case, (S,G) state on RP and  
> > PIMrtr would be constantly refreshed by data.
> >
> > --
> 
> First the spec then reality...
> Not quite true or there would be no need for the N-bit:
> 
>    N    The Null-Register bit. Set to 1 by a DR that is probing the RP
>         before expiring its local Register-Suppression timer. Set to 0
>         otherwise.
> 
> However, this is a case of following the spec to the letter vs doing  
> somthing
> that is "good enough" to accomplish the job.
> 
> By this I mean that the spec defines a "rp-probe time"
> 
> 
>    Timer Name: Register Stop Timer (RST(S,G))
> 
> 
>     
> +---------------------------+----------------------
> +--------------------+
>    |Value Name                 |Value                 | 
> Explanation       
>    |
>     
> +---------------------------+----------------------
> +--------------------+
>    |Register_Suppression_Time  |Default: 60 seconds   | 
> Period during     
>    |
>    |                           |                      | which 
> a DR stops  
>    |
>    |                           |                      | sending  
> Register-  |
>    |                           |                      | encapsulated  
> data  |
>    |                           |                      | to 
> the RP after   
>    |
>    |                           |                      | 
> receiving a       
>    |
>    |                           |                      | 
> RegisterStop      
>    |
>     
> +---------------------------+----------------------
> +--------------------+
>    |Register_Probe_Time        |Default: 5 seconds    | Time 
> before RST   
>    |
>    |                           |                      | 
> expires when a  
> DR  |
>    |                           |                      | may 
> send a Null-  
>    |
>    |                           |                      | 
> Register to the  
> RP |
>    |                           |                      | to 
> cause it to    
>    |
>    |                           |                      | 
> resend a          
>    |
>    |                           |                      | 
> RegisterStop      
>    |
>    |                           |                      | 
> message.          
>    |
>     
> +---------------------------+----------------------
> +--------------------+
> 
> 
> But what is the register used for?  To create state in the PIM-RP.
> 
> I'm going to cover lots of possibilities but not recommend anything in
> particular, However, if I were implementing a new PIM, I'd 
> want to make  
> sure
> I met all the following.
> 
> So back to creating state on the RP, that can easily be done 
> with just a
> NULL register to create (S,G) state.  Yes, that means that 
> there will  
> not
> be a data packet to send down the shared-path, but consider 
> that if the
> RP does not have (*,G) state you'll have done all that 
> encapsulating for
> no reason.  How expensive that encapsulating is, I don't care 
> to debate.
> 
> OK, if you -do- have (*,G) state, what is the first-thing the RP is  
> suppose
> to do?  Yes, decapsulate and send the packet down the 
> shared-tree, but  
> then
> -also- join immediately to the shortest-path to create the X-line  
> getting
> data to flow up to the RP.
> 
> Now, you have to worry about sending your register-stop.  If 
> you wait as
> required by the spec for data to arrive natively, you could 
> end up with
> the first-hop and the rp having full forwarding queues in 
> their Route  
> Processor
> (since data encap and decap happens on the route processor -- 
> let us not
> get into worrying about whether or not a vendor can install a separate
> processor to take care of this encapsulation since I agree it can be  
> done,
> but I would question why one would want/need to do it as you 
> will see.)
> 
> So, I submit to you that sending a single register to the RP 
> and having  
> the
> RP join to the SPT (X-line) would be "good enough".  Not 
> according to  
> the
> spec, but definitely "good enough".
> 
> Arguments about how this decision will result in lost packets to the  
> receiver
> are valid, but considering how horrible PIM ASM is at delivering all  
> the packets
> anyway -- who cares.
> 
> Now, there is the question about whether or not an encapped 
> data packet  
> is
> required in the register.  Remember the RP is going to join to the SPT
> and once the X-line is set up packets will get forwarded down 
> the shared
> tree at all intersections with the X-line.  (ie, all these turn-around
> routers are going to get set up).  This happens according to 
> the spec  
> now
> so it isn't like its an either/or situation.
> 
> So, I submit that including an encapsulated packet could be considered
> another over-engineered aspect of PIM-SM.
> 
> Now, remember that the last-hop router is going to join to the SPT  
> anyway.
> It has been shown that PIM-ASM, although designed to do so, can not
> effectively switch between the shared-tree and shortest-path in a
> manner that is reliable enough to not drop packets (or deliver
> duplicate packets, if not both).
> 
> The PIM-RP is used for source discovery.  In a more well-developed
> protocol and if we hadn't been on drugs for the last 10 
> years, we would
> have realized that having the network do source discovery -- 
> especially
> when talking about interdomain multicast -- is insane.  (Now is when
> this discussion will drift off into the SSM/Bidir vs Sparse mode  
> argument.
> Do understand that we -must- get there and we have to do whatever it
> takes to get there and all objections to the contrary which 
> insist that
> ASM is working are moot because ASM requires too many resources from
> the network and it always will -- but that doesn't mean that we can
> drop ASM today.
> 
> So we need to keep (S,G) alive on the PIM-RP for source discovery.
> PIM registers are the only way this can be accomplished.
> 
> AFAIC, I don't care if they are encapsulated, or NULL registers
> just as long as they get there every 3 minutes.
> 
> NOTE, the spec specifies that NULL registers are sent as a "probe"
> and that if a register-stop isn't received that an encapsulated
> register is sent.  In practice this "should" mean that the
> encapsulated register should never get sent.  It isn't clear to
> me why an RP that receives a NULL register but doesn't respond
> with a register stop will do any better with an encapsulated
> register, but I suppose an implementation might drop NULL registers
> (because of CRC errors or whatever) and not drop encaped registers.
> 
> So, bottom line, NULL registers _should_ be "good enough" for most
> implementations.  Make sure your NULL registers work.  Make sure
> that you can deal with a checksum over just the pim header and
> over the entire packet since some implementations do one and
> some do the other.
> 
> Now your ASM is "good enough" and you can move on to getting
> SSM/Bidir developed and deployed and use your political skills
> to get switches to support IGMPv3 snooping (or get GARP developed)
> and get applications to support SSM and Bidir and get some reliable
> source discovery system that doesn't require the network to store
> those sources.
> 
> Oh, and finally, find a way to deal with Beau's SSM DOS attack.
> 
> Pretending that ASM is going to work to get multicast to move beyond
> what it is now is putting our heads in the sand.
> 
> (Caveat, certain equipment vendors have a bounded network problem
> for which ASM may quite nicely meet all their requirements and for
> which SSM and Bidir may not add any functionality.  Great.  No
> argument.  But if your multicast is suppose to run across the internet
> or even in a large enterprise with large BW requirements, its time
> to move on.)
> 
> 
> > Sonum
> >
> > Initially the DR has no state and sends a register packet 
> to the RP  
> > that replies with a register-stop. The DR stops 
> encapsulation starts  
> > the
> > Now (for some reason) the SPT gets built, i.e., the DR receives an  
> > (S,G) join from PIMrtr. The DR starts forwarding data natively.
> >