Subject: RE: [pim] ID update for "Anycast-RP using PIM"

From: "Amit Shukla" <[email-masked]>
Date: Wed, 11 May 2005 22:13:27 -0700

Hi Dino,

Currently spec mention that -

   ".... an implementation MAY suppress sending Register-Stop
    messages in response to a Register received from an RP. If
    this is done, the Register-Stop caching option must be disabled"

I don't think we should allow supression of register-stop messages.
An implementation cannot reliably do register stop caching if 
suppression is allowed. If you feel we must allow suppression, then 
I would ask that caching be complety removed from the spec.

There are lot of intersting scenarios to be considered for 
register-stop caching, it`s more than keeping track of register-stops
coming from Anycast RP`s:

  - Anycast-RP receiving the register messages from DR may send a 
    join towards source while forwrding encapsulated data on RPT as
    well as replicating the register packets to other anycast-RP peers.

    Let`s say if RP start to receive mcast data on SPT before all the
    register-stops have arrived then should we not switch to SPT and 
    continue to receive Register packets until all the RP`s have
responded 
    with Register-stop`s ?

  - Let`s say RP already has <s,g> forwarding cache entry created and
now
    it receives Register message from DR. Should we switch from SPT to
RPT
    to achieve the goal of replicating the register packets to anycast
remote 
    rp`s until all the register-stop message`s are received ?

  - RP1 replicating registers to remote anycast RP`s RP2 and RP3.
    Let`s say RP2 goes down, in this case if RP2 loopback address wasn`t

    used then RP1 may continue to send Register packets to RP2 as it
    has no way to know RP2 is down. If register-stop caching is
supported then
    each RP`s loopback address should be used so that unicast routing
can at
    least detect Anycast-peer going down and stop sending register to
that RP.

Thanks
Amit

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 May 2005 11:10:48 -0700

>> I would ask that caching be complety removed from the spec.

    But are stated as MAYs which means it doesn't have to be implemented. The
    two implementations I know of do not.

>>     continue to receive Register packets until all the RP`s have

    Yes, it would have to but duplciates will not be sent down the RPT tree
    because if there was a (S,G) joiner in the RP's domain, it should be
    doing (S,G,RP-bit) pruning.

    If the (S,G) joiner is in another RP's domain, it *could* be getting 
    duplicates until the time it's RP can send the Register-Stop, *that is*
    only the case if the joiner's (S,G,RP-bit) prune hasn't been delivered
    to it's RP.

    But all of this is no differnt than ASM-based PIM-SM.

>>     rp`s until all the register-stop message`s are received ?

    Forwarding the packet via a register and deciding to send the packet down
    it's own RPT go by different rules. The former uses the rules in this ID
    and the later uses the rules from the main PIM-SM specification.

>>     has no way to know RP2 is down. If register-stop caching is

    Why do you bring a loopback address into this problem? What is the 
    relevance of it? I think you are saying RP2 really didn't go down but
    since it's RP address, assigned to one of it's attached interfaces, has
    gone down, then the Registers will get dropped by the network. Is this what
    you are trying to say? If so, I will answer below in this context.

>>     least detect Anycast-peer going down and stop sending register to

    Yes, this optimization can be performed. That is when an RP wants to
    forward a register and the configured RP address does not match any
    route in the unicast routing table, it can suppress sending the Register
    and treat the RP as if it had received a Register-Stop. That way when 
    Register-Stops have been received by all other RPs, this RP can send a
    Register-Stop to the DR.

    But your issue still exists if the network drops packets (for any reason),
    there would need to be a "give-up counter" that doesn't have to be per
    (S,G) route, but a global retry limit per RP in the anycast-RP set. 
    Null-Registers could be used for this. But again, it should be a MAY and 
    done only if Register-Stop caching is implemented.

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 12 May 2005 12:15:25 -0700

>    two implementations I know of do not.

Dino,
	I think you missed the point.  An RP that would like to do
	register-stop caching cannot do it if one or more of its
	anycast RP's do supression.

	Therefore, we must decide now if we are going to allow
	caching. If so, we MUST require a mandatory knob to
	disable supression or just not allow it at all.

	If you are going to allow implementations to always do supression
	then there is no reason to mention caching in the spec.

	So we either need to add something to the spec or take something out.

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 May 2005 12:37:26 -0700

>> 	anycast RP's do supression.

    Yes, I understand that. And the spec indicates that.

>> 	disable supression or just not allow it at all.

    I put caching in the spec because of the comments I have received. I 
    thought it was harmless to add so I did so to satisfy the reviewers. I
    indicated to the reviewers that I would envision most implementations 
    to not do Register-Stop caching.

    Yes, an implementation knob would be required.

>> 	then there is no reason to mention caching in the spec.

    The spec indicates MAY for suppression.

>> 	So we either need to add something to the spec or take something out.
  
    But there were many people satisfied with what I had. I would prefer to
    not reopen that can of worms.

Dino

P.S. "Anycast-PIM", the spec of perpetual last call.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 13 May 2005 15:02:32 +0200

Hi,

> 	anycast RP's do supression.

I think that's not exact.
As suggested earlier by Dino, a 'give up counter' is enough to solve
this issue.
(it could in practice be very low)

> 	disable supression or just not allow it at all.

Yes, that was my point in a previous post.

I think the spec would be robust enough by adding this and also
mentioning that implementing register-caching should include some give
up counter. 

-Thomas