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

From: "Amit Shukla" <[email-masked]>
Date: Thu, 14 Apr 2005 13:01:20 -0700

Hi Dino,

I`ve a question related to register-stop caching. In section 3.0, 
last 2 bullets mention that RP1 sends register stop back to DR 
when both RP2 and RP3 have returned register-stops. Does the 
similar action taken for periodic NULL-register messages send 
by DR to RP1, which is replicating it to all the RPs in the 
anycast-RP set ? If so then isn`t it possible that register probe
timer may expire on DR before RP1 gets all reister-stop messages 
back from anycast-RP set routers and send register-stop back to DR.

There is some discussion in the past regarding the possibilty of 
having loops as a result of mis-configuration. Can`t we reserve a bit 
in Register message, which indicates if the register packet is coming 
from RP. This way loop can be avoid and any mis-configuration can be 
easily detected if implementation generates log message saying that 
register message received from RP, which is not in anycast-rp set.

Minor correction, section 3.0 third paragraph source should be S3 
(not S2).

Thanks
Amit

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Apr 2005 11:13:54 -0700

>> anycast-RP set ? If so then isn`t it possible that register probe

    Yes, same action can occur for Null-Registers but it is not important
    because it is assumed (S,G) state has already been created in all RPs
    from data-Register messages.

>> back from anycast-RP set routers and send register-stop back to DR.

    It could, but just means an extra Null-Register is sent by the DR. No big
    deal I think.

>> in Register message, which indicates if the register packet is coming 

    That is the reason for the Register TTL copying logic. It's less evasive.

>> register message received from RP, which is not in anycast-rp set.

    You can issue this log message in any event (and don't have to wait for
    the loop). My implementation does this.

>> Minor correction, section 3.0 third paragraph source should be S3 

    Nice find, thanks. I have corrected it but won't issue an new ID for just 
    this. If there is another round of comments (which I hope there is not),
    your comment will get aggregated in

Thanks for the comments,
Dino