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

From: "Amit Shukla" <[email-masked]>
Date: Sat, 14 May 2005 16:04:41 -0700

I was raising a different issue, where inconsistently configured anycast-RP
sets could result in loop. Spec currently recommends copying the TTL
from a register message to the register messages it copies and send to 
other RPs. I understand that copying the TTL does terminate any loop 
started by mis-configuration. My question/suggestion was that why can`t 
we reserve a bit in register message, which is set to 1 when RP is copying 
and sending register to other anycast-RP`s. Doing this will not let any loop 
start at first place and any mis-configuration can be easily detected. 
 
There is no change on the DR as it should continue to send the way it 
originates Register message (setting the reserved bits to 0). Yes, it could 
be a problem if there are any DR`s out there, which is not setting the 
reserverd bits to 0 but that would be wrong since you can never utilize 
these bits in future.
 
In past discussion you pointed out that it creates an interop issue with 
older RP`s to which we can`t dictate this new behaviour. Can you please 
elaborate that, my understanding is that older-RP should just ignore this bit.
 
If there any older RP`s in the field which is supporting this draft then they won`t 
be able to set this bit in that case we can continue to keep the copying TTL 
logic along with register bit identification information. Also, new RP`s should 
be prepared to receive the register packets coming from older anycast-RP peer 
without this bit being set.

- Amit

________________________________

From: Dino Farinacci [mailto:[email-masked]]
Sent: Fri 5/13/2005 10:21 PM
To: Amit Shukla
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] ID update for "Anycast-RP using PIM"

>> There has not been a new spec released since we discussed this.
>> If you now believe my questions are covered in the most recent
>> spec, please let me know which section you are referring to.

    draft-ietf-pim-anycast-rp-03.txt is the latest spec and I believe your concern
    is stated here, in section 4.0, titled "Observations and Guidelines about this
    Proposal":

   o Logic is changed only in the RPs. The logic change is for
     sending copies of Register messages. Register-Stop processing is
     unchanged. However, 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.

>> Please let me know if you want me to restate the issue.

    I don't think you need to.

Dino   

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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 15 May 2005 10:01:52 -0700

>> start at first place and any mis-configuration can be easily detected. 

    Why do we need to make another change to the spec? TTL is sufficient in
    the rare cases of misconfigurations (yes, misconfigurations happen but
    people do want their networks to work).

    Again, I want to make as few as changes as possible to the base PIM message
    format.

Dino