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

From: Bill Fenner <[email-masked]>
Date: Sun, 3 Apr 2005 19:34:23 -0800

Dino,

  Thanks for the update.  I still have a couple of concerns:

1. When the description of the behavior doesn't match the behavior
specified in pim-sm-v2-new, it's not clear if it's because you're
taking shortcuts in describing the procedure or because Anycast-RP
requires it.  For example, you say that RP1 sends a Register-Stop
back to the DR.  pim-sm-v2-new says that you only send a Register-Stop
if the SPT bit is set, or SwitchToSPTDesired is true for that (S,G)
but your oiflist is null.  Neither of them seem like they would
be true in this point in your narrative, so it's not clear why
RP1 sends the Register-Stop immediately - is this a change that's
necessary for Anycast-RP functionality or is it just a different way
of describing the protocol behavior?

(This echoes James Lingard's comments)

2. I still have the concern about the source address that I mentioned
in my earlier message - misconfiguration can cause loops; the TTL
copying helps but the description talks about "RP1 inserts its
address"; I'd guess that enough RPs have multiple interfaces that
that's not specific enough.  I think the following would be enough
in section 4:

o It is important for each RP to use the source address that is
  configured at the other RPs to originate its Register messages.
  If it uses an address assigned to the router that is not the one
  configured on the other RPs, loops can result.

3. Also, I mentioned in my earlier message, I think it's confusing to
say "...responsiblility of the RP the DR selects..." since the DR
isn't doing anything active to select an RP; I think "reaches" expresses
what actually happens better.

4. Something I didn't notice in my earlier review - you're using
RFC 2362 as the PIM spec reference; pim-sm-v2-new is in the IESG's
hands so I think it's appropriate to use that.  (If you're doing
that for a reason other than not wanting to be blocked by the
reference to the I-D, please let me know!)

  Bill

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

---

From: "James Lingard" <[email-masked]>
Date: Mon, 4 Apr 2005 14:01:36 +0100

Bill,

Actually your point 2 is incorrect about the potential for loops.  This is something that I have discussed with Dino and Yiqun recently.

The new draft says (in section 3.0, bullet 4):

   o RP1 is configured with RP2 and RP3's IP address. Since the
     Register message did not come from one of the RPs in the
     anycast-RP set, RP1 assumes the packet came from a DR. If the
     Register is not addressed to the Anycast-RP address, an error
     has occurred and it should be rate-limited logged.

So in the situation you describe, the receiving router believes that the Register message has come from a DR because its source address is not in its configured set.  But then the receiving router compares the destination address against the Anycast-RP address, and since they are not the same the receiving router ignores the Register message (and logs an error).

I think that the draft as it currently stands has no potential for looping, even under misconfiguration.  But the draft should probably be changed to explain more clearly why this is the case, since this is obviously not clear to you (and it previously wasn't clear to me either).

Regards,
James.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 04 April 2005 04:34
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] ID update for "Anycast-RP using PIM"

Dino,

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Mon, 4 Apr 2005 08:05:52 -0800

Aha, thanks for pointing that out.  You're right, I completely
missed that.

  Bill

---

From: "James Lingard" <[email-masked]>
Date: Tue, 5 Apr 2005 14:41:34 +0100

Dino,

Comments inline enclosed in [JL]...[/JL].

James.

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]]
Sent: 04 April 2005 21:52
To: James Lingard
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pim] ID update for "Anycast-RP using PIM"

    This email addresses all commenters. The next rev of the draft is enclosed
    below.

James>> As I believe I suggested to you before (and I think Bill and Thomas were hinting at the same), I think that the protocol description would be significantly clearer if it was more in the style of draft-ietf-pim-sm-v2-new-11.  For example, if the description of the behavior at an RP was in terms of modifications to the the pseudocode in section 4.4.2 of that draft, or even if you just make more reference to concepts such as SwitchToSptDesired(S,G), KAT(S,G), etc.  This might be a rather major change to the document, but if you agree that it would be an improvement but don't have time to do it, I'd be glad to assist.

    Since the Anycast-PIM ID was written a long time ago and the PIM ID was 
    still in flux, I didn't want to reference it. I would prefer to not change
    the format since it will be more trouble than it is worth.

[JL]
Fair enough.
[/JL]

    I do believe the PIM spec is very precise in its specification. But I
    believe using more English lends itself to a clearer understanding for
    not only the implementor but also for all other types of readers (which
    there are more of). I would prefer to not use the PIM-ID language and
    write clear English.

[JL]
English is fine, as long as it's clear.  I don't believe the current document is clear, as evidenced by my comments below, and I think that it will be difficult to make it clear without some reference to the PIM-SM spec.  At present, it isn't clear when you're trying to describe the same behavior as the PIM-SM spec, but in different terminology, and when you're trying to specify modifications to the base PIM-SM behavior.
[/JL]

James>> Does RP1 have to send a Register-Stop back to the DR, and have to
James>> create (S1,G) state?  That is, do we force SwitchToSptDesired(S,G)
James>> to be TRUE at RP1?
James>> 
James>> If so, a brief explanation of why would be useful.  And you should
James>> also say that RP1 MUST join back to the source-tree if there are
James>> receivers (that is, if inherited_olist(S,G) is non-NULL).
James>> 
James>> In any case, RP1 shouldn't send a Register-Stop back to the DR
James>> unless the SPT is already established or there are no receivers
James>> (that is, inherited_olist(S,G) is NULL).

    I wanted the action to be the same actions as done in the base PIM spec.
    And I didn't want to specify it here or else we would have duplicate text
    which is difficult to maintain.

[JL]
OK, but currently the actions are _not_ the same as in the base PIM spec.  In the base PIM spec, whether or not RP1 sends a Register-Stop back to the DR depends on SwitchToSptDesired(S,G), which you make no reference to here; you seem to assume that it is TRUE.
[/JL]

James>> "However, RP1 MUST create (S1,G) state."  How long for?  The
James>> answer is given in section 4.4.2 of draft-ietf-pim-sm-v2-new-11, and
James>> it depends upon the circumstances as to whether it's KAT_Period or
James>> RP_KAT_Period.  But without referring to the relevant sections of
James>> that draft directly, it's not obvious.

    Whatever the new PIM spec says. I don't want to duplicate the PIM spec
    and risk having contradictions. So this spec is a bit under-specified on
    purpose.

[JL]
OK, I guess.
[/JL]

James>> "RP2 MAY wait to send the Register-Stop if it decides to join the
James>> source-tree."
James>> 
James>> "RP2 should wait until it has received data from the source on the
James>> source-tree before sending the Register-Stop."
James>> 
James>> Aren't these two sentences identical except for their use of "MAY"
James>> and "should"?

    No, they are not the same. The first says RP2 doesn't have to send a
    Register-Stop at all. The second indicates if it decides to, describe
    when should it.

[JL]
Are you trying to say something like the following?

   o RP2 sends a Register-Stop back to the RP1. If RP2 decides to join the
     source-tree, it MAY wait to send the Register-Stop until it has
     received data from the source on the source-tree. Otherwise, the
     Register-Stop is sent immediately. If RP2 decides to wait, it will
     need to remember that the Register was originated by RP1.

Note also that you have a typo in "originated".
[/JL]

James>> Anyway, since RP2 has receipients for (*,G), surely
James>> it MUST join the source-tree, and MUST wait before sending the
James>> Register-Stop?

[JL]
I don't think you answered this question.
[/JL]

James>> "If RP2 decides to wait, it will need to remember that the Register
James>> was origianted [sic] by RP1."
James>> 
James>> Why does it need to remember this?  In regular PIM-SM, Register-Stop
James>> messages are only ever sent on receipt of a Register message
James>> (otherwise the RP would need to remember the DR address for every
James>> S).  Are you proposing a fundamental change here?

    Usually if a Register-Stop is sent in response to a Register, you have
    the source IP address handy from the Register so you can use it for the
    destination of the Register-Stop. If you send the Register-Stop later,
    you have to remember who sent the Register(s).

[JL]
I don't understand what you're saying here.  Are you trying to describe regular
PIM-SM behavior?  Because in regular PIM-SM, Register-Stop messages are
_only ever_ sent in response to a Register, so you _never_ need to remember who
sent the Register.

Are you proposing to change this?
[/JL]

James>> Surely RP2 MUST join back to the source-tree, or else R2 won't
James>> receive data from S1?

    Not if register encapsulation is used *only* for data transfer. There are
    many combinations that could occur (where some RPs join back to the source,
    others don't, etc) which I would prefer to have them all be consistent
    about.

[JL]
So are you saying that it's legitimate for RP2 to choose not to join back to the
source-tree, and to choose to continue to receive data via Register messages
indefinitely?

This is not what I had understood from a previous discussion we had.
[/JL]

James>> As above, how long does RP3 create (S1,G) state for?

    Main PIM spec says.

James>> Why does RP1 need to process and cache the Register-Stop messages at
James>> all?  You don't say anywhere what it does with them.

    Because you want to keep receiving Registers from the DR, in case a
    Register was lost when being propogated from one RP to another.

[JL]
I had previously understood that Null-Registers ought to be sufficient for this
purpose.  If the original Register message(s) are dropped between RP1 and RP2,
each Null-Register message is also copied by RP1 and sent to RP2.  This provides
a basic degree of robustness to packet loss, without the complexity of having to
store state per-(S,G), per-RP.

If we're going down this route, I have the following question.
If RP2 sends a Register-Stop, but RP3 doesn't, should RP1 copy Register messages
only to RP3, or should it still copy them to both RP2 and RP3?
[/JL]

    A
    Register-Stop in this case is an ack that the Register receiving RP has
    received and forwarded the data in the Register.

    So what I did is remove higher up that RP1 should send a Register-Stop
    to DR to the last bullet where it will wait for Register-Stops from all
    RPs. That should make the logic flow better.

James>>Section 4.0.
James>>
James>>   o An RP that doesn't support this specification can be mixed with
James>>     RPs that do support this specification. However, the non-supporter
James>>     RPs should not have sources registering to it but may have receivers
James>>     joined to it.
James>>
James>>This is only true as long as the non-supporter RPs always have
James>>SwitchToSptDesired(S,G) == TRUE for all (S,G).

    Yes, what is true of most implementations by default.

[JL]
Most, but not necessarily all.
[/JL]

James>>Front page: copyright date should be 2005.
James>>
James>>Section 4.0, first bullet: "by copy the TTL" -> "by copying the TTL".
James>>
James>>Section 4.0, fourth bullet: change
James>>
James>>   o The source gets Registered to a single RP by the DR, it's the
James>>     responsibility of the RP, the DR selects (based on routing
James>>     metrics), to get the packet to all other RPs in the Anycast-RP
James>>     set.
James>>
James>>to:
James>>
James>>   o The source gets Registered to a single RP by the DR. It's the
James>>     responsibility of the RP that receives the PIM Register
James>>     messages from the DR (the closest RP to the DR based on routing
James>>     metrics) to get the packet to all other RPs in the Anycast-RP
James>>     set.
James>>
James>>References: update [I2] to revision -11, dated October 2004.

    I have made all these changes. Thanks.

[JL]
You don't appear to have made the "copy" -> "copying" change.

Another typo in Section 3.0, paragraph 3:
"needs to be a different" -> "needs to be different"
[/JL]

James>> So in the situation you describe, the receiving router believes that the Register message has come from a DR because its source address is not in its configured set.  But then the receiving router compares the destination address against the Anycast-RP address, and since they are not the same the receiving router ignores the Register message (and logs an error).

    But one of the anycast-RP set of addresses configured could be the 
    Anycast RP address. You just can't say how simple the misconfiguration 
    could be. ;-)

[JL]
An implementation mustn't allow itself to be configured such that the Anycast-RP address is itself in the set of RP addresses for that Anycast-RP address.  That's a very simple check, which you could add to the spec.  Provided this check is made, no loops (with >1 cycle) can occur if all routers agree on RP(G).

If routers disagree on RP(G) then you are correct, loops (with >1 cycle) can occur, and I don't think there's anything an implementation can do about it.
[/JL]

Thanks all for your comments,
Dino and Yiqun