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

From: "Amit Shukla" <[email-masked]>
Date: Mon, 18 Apr 2005 13:13:28 -0700

Hi Dino.

Thanks for your response. Please see my comments inline.

>> 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.

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

I don`t think it`s just an extra Null-register message, as per the PIM
draft, when register-stop (probe) timer is started we move to
"Join-Pending"
state and upon timer expiry there is a state transition to "Join(J)" and

register tunnel interface is added back to start forwarding Register
message 
(encapsulating data packets). Depending upon source sending rate, number
of
register messages will be forwarded until Register-stop is returned back
by 
RP (after collecting all the responses).

So every 65 seconds (suppression + probe timer) DR will start sending
non-NULL
register packets. It`s not worth waiting for all the register-stop
responses 
for NULL-register packets as you said <s,g> state is already created.
I`m not 
sure if spec should mention this kind of thing.

>> 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

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

Doesn`t register TTL copying logic rely upon TTL to become 0 to detect
loops ?
It may be evasive but having a bit in Register message itself will not
even let 
the loop start at first place in any mis-configuration. It`s for
different 
reason but today Register message have a bit indicating if they are
coming from 
DR or PMBR. 

Regards
Amit

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

---

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

>> RP (after collecting all the responses).

    Yes, additional Registers.

>> sure if spec should mention this kind of thing.

    The implementations of this draft that I know of do not do this 
    Register-Stop waiting. In addition, the latest draft says an implementation
    MAY do this. So it is not required.

>> sure if spec should mention this kind of thing.

    BTW, it *could* be worth it if one of the RPs had lost it's (S,G) state
    and you want data-Registers to quickly reinstantiate the state at the
    rate the source is sending (or some close approximation).

>> Doesn`t register TTL copying logic rely upon TTL to become 0 to detect

    Yes. But we are not detecting loops per say, we are stopping them for
    a ttl-value of times.

>> It may be evasive but having a bit in Register message itself will not

    You also want this to work with older RPs as well, and you can't dictate
    new behavior in them.

>> reason but today Register message have a bit indicating if they are

    Understand. What do other people think? 

Dino