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

From: "James Lingard" <[email-masked]>
Date: Fri, 1 Apr 2005 12:42:10 +0100

Dino,

Here are my comments on your latest draft.

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.

That aside, here are some more specific comments.

Regards,
James.

====================================================================
Section 3.0, second bullet.

Change:

   o The DR directly attached to S1 will form a PIM Register message to
     send to RP1. The IP address to use is the Anycast-RP address.

to:

   o The DR directly attached to S1 will form a PIM Register
     message to send to the Anycast-RP address (RPA). The unicast
     routing system will deliver the PIM Register message to the
     nearest RP, in this case RP1.

====================================================================
Section 3.0, sixth and seventh bullets.

Does RP1 have to send a Register-Stop back to the DR, and have to
create (S1,G) state?  That is, do we force SwitchToSptDesired(S,G)
to be TRUE at RP1?

If so, a brief explanation of why would be useful.  And you should
also say that RP1 MUST join back to the source-tree if there are
receivers (that is, if inherited_olist(S,G) is non-NULL).

In any case, RP1 shouldn't send a Register-Stop back to the DR
unless the SPT is already established or there are no receivers
(that is, inherited_olist(S,G) is NULL).

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

====================================================================
Section 3.0, tenth bullet.

"RP2 MAY wait to send the Register-Stop if it decides to join the
source-tree."

"RP2 should wait until it has received data from the source on the
source-tree before sending the Register-Stop."

Aren't these two sentences identical except for their use of "MAY"
and "should"?  Anyway, since RP2 has receipients for (*,G), surely
it MUST join the source-tree, and MUST wait before sending the
Register-Stop?

"If RP2 decides to wait, it will need to remember that the Register
was origianted [sic] by RP1."

Why does it need to remember this?  In regular PIM-SM, Register-Stop
messages are only ever sent on receipt of a Register message
(otherwise the RP would need to remember the DR address for every
S).  Are you proposing a fundamental change here?

====================================================================
Section 3.0, eleventh bullet.

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

====================================================================
Section 3.0, thirteenth bullet.

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

====================================================================
Section 3.0, final bullet.

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

====================================================================
Section 4.0.

   o An RP that doesn't support this specification can be mixed with
     RPs that do support this specification. However, the non-supporter
     RPs should not have sources registering to it but may have receivers
     joined to it.

This is only true as long as the non-supporter RPs always have
SwitchToSptDesired(S,G) == TRUE for all (S,G).

====================================================================
A few editorial corrections.

Front page: copyright date should be 2005.

Section 4.0, first bullet: "by copy the TTL" -> "by copying the TTL".

Section 4.0, fourth bullet: change

   o The source gets Registered to a single RP by the DR, it's the
     responsibility of the RP, the DR selects (based on routing
     metrics), to get the packet to all other RPs in the Anycast-RP
     set.

to:

   o The source gets Registered to a single RP by the DR. It's the
     responsibility of the RP that receives the PIM Register
     messages from the DR (the closest RP to the DR based on routing
     metrics) to get the packet to all other RPs in the Anycast-RP
     set.

References: update [I2] to revision -11, dated October 2004.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 23 March 2005 01:25
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [pim] ID update for "Anycast-RP using PIM"

    See enclosed. I have not submitted to ID directory. Since -02 went to IESG,
    I would like to get okay from WG before resubmitting. So then -03 can go 
    through quickly.

Thanks,
Dino/Yiqun

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

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

---

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

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.

    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.

James>> to:
James>> 
James>>    o The DR directly attached to S1 will form a PIM Register
James>>      message to send to the Anycast-RP address (RPA). The unicast
James>>      routing system will deliver the PIM Register message to the
James>>      nearest RP, in this case RP1.

    Added.

>> create (S1,G) state?  That is, do we force SwitchToSptDesired(S,G)

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.

    I would like to leave it as is:

o RP1 will then send  a copy of the Register message from S1's 
  DR to both RP2 and RP3. RP1 will use its own IP address as 
  the source address for the PIM Register message.

o RP1 sends a Register-Stop back to the DR.

o RP1 MAY join back to the source-tree by triggering a (S1,G) Join 
  message toward S1. However, RP1 MUST create (S1,G) state.

-----

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.

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

    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.

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

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.

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

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.

Bill>> 1. When the description of the behavior doesn't match the behavior
Bill>> specified in pim-sm-v2-new, it's not clear if it's because you're
Bill>> taking shortcuts in describing the procedure or because Anycast-RP
Bill>> requires it.  For example, you say that RP1 sends a Register-Stop

    It's because I want to refer to the operations in the main spec. Should
    I say "where not specified, do as the pim-new spec does"?

Bill>> back to the DR.  pim-sm-v2-new says that you only send a Register-Stop
Bill>> if the SPT bit is set, or SwitchToSPTDesired is true for that (S,G)
Bill>> but your oiflist is null.  Neither of them seem like they would

    Yes, I didn't want to specify all that detail and wanted to yield to the 
    higher authority spec.

Bill>> be true in this point in your narrative, so it's not clear why
Bill>> RP1 sends the Register-Stop immediately - is this a change that's
Bill>> necessary for Anycast-RP functionality or is it just a different way
Bill>> of describing the protocol behavior?

    I have fixed this.

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

    I indicated in the previous version it is the address that is configured
    in the Anycast-RP set in all other RPs as you cited below:

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

    And James, loops can result, because if the source address of a Register
    is not in the anycast-RP set configured, the local RP will think the
    Register is from a DR (and not the another RP) and will propogate it.

    So when we say loops, we mean the packet could return to the original
    router. So that is a loop that cycles once. However, if the propogated
    Register is also not from an address in that list, the local RP (which 
    gets the packet back from another RP) will think it's from a DR -- and
    the loop with cycle > 1 will result.

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

    I could have missed this. The intention wasn't to ignore your comment. But
    based on James rewrite of this I want to keep the word "responsibility" in
    the description. This bullet is in the observation section so it is not 
    describing elements of procedure but making some observations about how 
    the source gets known to all other RPs. So it's the RP responsibility to 
    get the source known to all other RPs and not the source's responsibility.

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

    I will swap and make 2362 an informational reference and -11 normative
    reference.

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

Thanks all for your comments,
Dino and Yiqun

-------------------------------------------------------------------------------

Network Working Group                                     Dino Farinacci
INTERNET-DRAFT                                                 Yiqun Cai
Expiration Date: October 2005                              cisco Systems
                                                           April 4, 2005

                          Anycast-RP using PIM
                   <draft-ietf-pim-anycast-rp-03.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This specification allows Anycast-RP (Rendezvous Point) to be used
   inside a domain, which runs Protocol Independent Multicast (PIM)
   only. There are no other multicast protocols required to support
   Anycast-RP, such as MSDP, which has been used traditionally to solve
   this problem.

Farinacci, Cai                                                  [Page 1]

Internet Draft            Anycast-RP using PIM             April 4, 2005

1.0 Introduction

   Anycast-RP as described in [I1] is a mechanism ISP-based backbones
   have used to get fast convergence when a PIM Rendezvous Point (RP)
   router fails. To allow receivers and sources to Rendezvous to the
   closest RP, the packets from a source needs to get to all RPs to find
   joined receivers.

   This notion of receivers finding sources is the fundamental problem
   of source discovery which MSDP was intended to solve. However, if one
   would like to retain the Anycast-RP benefits from [I1] with less
   protocol machinery, removing MSDP from the solution space is an
   option.

   This memo extends the Register mechanism in PIM so Anycast-RP
   functionality can be retained without using MSDP.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.0 Requirements

   o Each router acting as an RP MUST be configured with a loopback
     interface using the same (shared) IP address. This address is used
     to tell other routers in the PIM domain what IP address to use
     for the RP address.

   o The RP address or a prefix that covers the RP address is injected
     into the unicast routing system inside of the domain.

   o Each RP configures all other RPs used in the Anycast-RP set. This
     must be consistently configured in all RPs in the set.

Farinacci, Cai                                                  [Page 2]

Internet Draft            Anycast-RP using PIM             April 4, 2005

3.0 Mechanism

   The following diagram illustrates a domain using 3 RPs where
   receivers are joining to the closest RP according to where unicast
   routing metrics take them and 2 sources sending packets to their
   respective RPs.

         S1-----RP1              RP2                RP3------S3
                / \               |
               /   \              |
              R1   R1'            R2

   Assume the above scenario is completely connected where R1, R1', and
   R2 are receivers for a group, and S1 and S2 send to that group.
   Assume RP1, RP2 and RP3 are all assigned the same IP address which is
   used as the Anycast-RP address (let's say the IP address is RPA).

   Note, the address used for the RP address in the domain (the
   Anycast-RP address) needs to be a different than the addresses used
   by the Ancyast-RP routers to communicate with each other.

   The following procedure is used when S1 starts sourcing traffic:

   o S1 sends a multicast packet.

   o RP1 will receive the PIM Register message, decapsulate it, send the
     packet down the shared-tree to get the packet to receivers R1 and
     R1'.

   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.

   o RP1 will then send  a copy of the Register message from S1's
     DR to both RP2 and RP3. RP1 will use its own IP address as
     the source address for the PIM Register message.

   o RP1 MAY join back to the source-tree by triggering a (S1,G) Join
     message toward S1. However, RP1 MUST create (S1,G) state.

   o RP2 receives the Register message from RP1, decapsulates it, and

Farinacci, Cai                                                  [Page 3]

Internet Draft            Anycast-RP using PIM             April 4, 2005

     also sends the packet down the shared-tree to get the packet to
     receiver R2.

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

   o RP2 MAY join back to the source-tree by triggering a (S1,G) Join
     message toward S1. However, RP2 MUST create (S1,G) state.

   o RP3 receives the Register message from RP1, decapsulates it, but
     since there are no receivers joined for the group, it can discard
     the packet.

   o RP3 sends a Register-Stop back to the RP1.

   o RP3 creates (S1,G) state so when a receiver joins after S1 starts
     sending, RP3 can join quickly to the source-tree for S1.

   o RP1 processes the Register-Stop from each of RP2 and RP3. RP1 needs
     to cache on a per-RP/per-(S,G) basis the receipt of Register-Stop
     messages from the RPs in the anycast-RP set.

   o RP1 sends a Register-Stop back to the DR when all RPs in the Anycast-RP
     set have returned Register-Stops for a particular (S,G) route.

   The procedure for S3 sending follows the same as above but it is RP3
   which sends a copy of the Register originated by S3's DR to RP1 and
   RP2. Therefore, this example shows how sources anywhere in the
   domain, associated with different RPs, can reach all receivers, also
   associated with different RPs, in the same domain.

4.0 Observations and Guidelines about this Proposal

   o An RP will send a copy of a Register only if the Register is received
     from an IP address not in the Anycast-RP list (i.e. the Register
     came from a DR and not another RP). An implementation SHOULD safeguard
     against inconsistently configured anycast-RP sets in each RP by copy the
     TTL from a Register message to the Register messages it copies and sends
     to other RPs.

   o Each DR that PIM registers for a source will send the message to the
     anycast-RP address (which results in the packet getting to the closest
     physical RP). Therefore there are no changes to the DR logic.

Farinacci, Cai                                                  [Page 4]

Internet Draft            Anycast-RP using PIM             April 4, 2005

   o Packets flow to all receivers no matter what RP they have joined to.

   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.

   o The rate-limiting of Register and Register-Stop messages are done
     end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no
     need for specific rate-limiting logic between the RPs.

   o When topology changes occur, the existing source-tree adjusts as it
     does today according to [N1]. The existing shared-trees, as well,
     adjust as it does today according to [N1].

   o Physical RP changes are as fast as unicast route convergence.
     Retaining the benefit of [I1].

   o If Null Registers are sent (Registers with an IP header and no IP
     payload), they MUST be replicated to all of the RPs in the Anycast-
     RP set so that source state remains alive for active sources.

   o The number of RPs in the Anycast-RP set should remain small so the
     amount of non-native replication is kept to a minimum.

5.0 Interaction with MSDP running in an Anycast-PIM Router

   The objective of this Anycast-PIM proposal is to remove the
   dependence on using MSDP. This can be achieved by removing MSDP
   peering between the Anycast RPs. However, to advertise internal
   sources to routers outside of a PIM routing domain and to learn

Farinacci, Cai                                                  [Page 5]

Internet Draft            Anycast-RP using PIM             April 4, 2005

   external sources from other routing domains, MSDP may still be
   required.

5.1 Anycast-PIM Stub Domain Functionality

   In this capacity, when there are internal sources that need to be
   advertised externally, an Anycast-RP which receives a Register
   message, either from a DR or an Anycast-RP, should process it as
   described in this specification as well as how to process a Register
   message as described in [N1]. That means an SA for the same internal
   source could be originated by multiple Anycast-RPs doing the MSDP
   peering. There is nothing inherently wrong with this other than the
   source is being advertised into the MSDP infrastructure from multiple
   places from the source domain. However, if this is not desirable,
   configuration of one or more (rather than all) Anycast-RP MSDP
   routers would allow only those routers to originate SAs for the
   internal source. And in some situations, there is a good possibility
   not all Anycast-RPs in the set will have MSDP peering sessions so
   this issue can be mitigated to a certain extent.

   From an Anycast-RP perspective, a source should be considered
   internal to a domain, when it is discovered by an Anycast-RP through
   a received Register message. Regardless, if the Register message was
   sent by a DR, another Anycast-RP member, or the router itself.

   For learning sources external to a domain, the MSDP SA messages could
   arrive at multiple MSDP-peering Anycast-RPs. The rules for processing
   an SA, according to [I1], should be followed. That is, if G is joined
   in the domain, an (S,G) join is sent towards the source. And if data
   accompanies the SA, each Anycast-PIM RP doing MSDP peering will
   forward the data down each of their respective shared-trees.

   The above assumes each Anycast-RP has external MSDP peering
   connections.  If this is not the case, the Anycast-PIM routers with
   the MSDP peering connections would follow the same procedure as if a
   Data-Register or Null-Register was received from either a DR or
   another Anycast-RP. That is, they would send Registers to the other
   members of the Anycast-RP set.

   If there is a mix of Anycast-RPs that do and do not have external
   MSDP peering connections, then the ones that do must be configured
   with the set that do not. So Register messages are sent only to the
   members of the Anycast-RP set that do not have external MSDP peering
   connections.

Farinacci, Cai                                                  [Page 6]

Internet Draft            Anycast-RP using PIM             April 4, 2005

5.2 Anycast-PIM Transit Domain Functionality

   Within a routing domain, it is recommended that an Anycast-RP set
   defined in this specification should not be mixed with MSDP peering
   among the members. In some cases, the source discovery will work but
   it may not be obvious to the implementations what sources are local
   to the domain and which are not. This may affect external MSDP
   advertisement of internal sources.

   Having said that, this draft makes no attempt to connect MSDP peering
   domains together by using Anycast-PIM inside a transit domain.

6.0 IANA Considerations

   This document makes no request to IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.0 Security Consideration

   This section describes the security consideration for Register and
   Register-Stop messages between Anycast-RPs.  For PIM messages between
   DR and RP, please see [I3].

7.1 Attack Based On Forged Messages

   An attacker may forge a Register message using one of the addresses
   in the Anycast-RP list in order to achieve one or more of the
   following effects:

      1. Overwhelm the target RP in a denial-of-service attack
      2. Inject unauthorized data to receivers served by the RP
      3. Inject unauthorized data and create bogus SA entries in other
         PIM domains if the target RP has external MSDP peerings

   An attacker may also forge a Register-Stop message using one of the
   addresses in the Anycast-RP list.  However, besides denial-of-
   service, the effect of such an attack is limited because an RP
   usually ignores Register-Stop messages.

7.2 Protect Register and Register-Stop Messages

   The DOS attack using forged Register or Register-Stop messages can
   not be prevented.  But the RP can still be protected.  For example,
   the RP can rate-limit incoming messages.  It can also choose to
   refuse to process any Register-Stop messages.  The actual protection

Farinacci, Cai                                                  [Page 7]

Internet Draft            Anycast-RP using PIM             April 4, 2005

   mechansim is implementation specific.

   The distribution of unauthorized data and bogus SA entries can be
   prevented using the method recommended in [I3].  That is IPsec [I3]
   transport mode using the Authentication Header (AH).

   There are two options a network administrator can choose from.  An RP
   can be configured using a unique SA and SPI for traffic (Registers or
   Register-Stops) to each member of Anycast-RPs in the list.
   Alternatively, a single authentication algorithm and associated
   parameters can be used for the entire Anycast-RP set in order to
   reduce the overhead of key distribution.

Farinacci, Cai                                                  [Page 8]

Internet Draft            Anycast-RP using PIM             April 4, 2005

8.0 Acknowledgments

   The authors would like to thank Yiqun Cai and Dino Farinacci for
   prototyping this draft in the cisco IOS and Procket implementations,
   respectively.

   The authors would like to thank John Zwiebel for doing
   interoperability testing of the two prototype implementations.

   The authors would like to thank Thomas Morin from France Telecom for
   having an extensive discussion on Multicast the Registers to an SSM-
   based full mesh among the anycast-RP set. This idea may come in a
   subsequent Internet Draft.

   And finally, the authors would like to thank the following for their
   comments on earlier drafts:

      Greg Shepherd (Procket Networks (now cisco Systems))
      Lenny Giuliano (Juniper Networks)
      Prashant Jhingran (Huawei Technologies)
      Pekka Savola (CSC/FUNET)
      Bill Fenner (AT&T)
      James Lingard (Data Connection)

9.0 Author Information

   Dino Farinacci
   cisco Systems
   [email-masked]

   Yiqun Cai
   cisco Systems
   [email-masked]

10.0 References

10.1 Normative References

   [N1] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent
        Multicast - Sparse Mode (PIM-SM):Protocol Specification
        (Revised)", Internet Draft draft-ietf-pim-sm-v2-new-11.txt,
        October 2004.

10.2 Informative References

Farinacci, Cai                                                  [Page 9]

Internet Draft            Anycast-RP using PIM             April 4, 2005

   [I1] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM
        and MSDP", RFC 3446, January 2003.

   [I2] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
        SM): Protocol Specification", RFC 2362, June 1998.

   [I3] Kent, "Security Architecture for the Internet Protocol", RFC 2401,
        November 1998.

Farinacci, Cai                                                 [Page 10]

Internet Draft            Anycast-RP using PIM             April 4, 2005

Appendix A - Possible Configuration Language

   A possible set of commands to be used could be:

       ip pim anycast-rp <anycast-rp-addr> <rp-addr>

   Where:

       <anycast-rp-addr> describes the Anycast-RP set for the RP which
       is assigned to the group range. This IP address is the address
       that first-hop and last-hop PIM routers use to register and join
       to.

       <rp-addr> describes the IP address where Register messages copies are
       sent to. This IP address is any address assigned to the RP router
       not including the <anycast-rp-addr>.

   Example:

       From the illustration above, the configuration commands would be:

       ip pim anycast-rp RPA RP1
       ip pim anycast-rp RPA RP2
       ip pim anycast-rp RPA RP3

   Comment:

       It may be useful to include the local router IP address in the
       command set so the above lines can be cut-and-pasted or scripted
       into all the RPs in the Anycast-RP set.

       But the implementation would have to be aware of its own address
       and not inadvertently send a Register to itself.

Farinacci, Cai                                                 [Page 11]

-------------------------------------------------------------------------------

---

From: MORIN Thomas RD-CORE-LAN <[email-masked]>
Date: Mon, 11 Apr 2005 18:06:29 +0200

Hi Dino,

Dino Farinacci :
>     This email addresses all commenters. The next rev of the draft is
> enclosed below.
> 
[snip]

I have a few comments, inline below.

>      message toward S1. However, RP2 MUST create (S1,G) state.

I think those two bullets could be merged : first phrase of latter bullet 
somehow duplicates what's in the former.

Also, as currently stated it is not clear that RP2 MUST send a
register-stop, and this is not required by the PIM spec either... 

Perhaps something like :

o  RP2 may join source tree  ...

o  RP2 MUST send a register stop, ... MUST create (S1,G) state

?

>    o RP1 processes the Register-Stop from each of RP2 and RP3.  RP1 
>      needs to cache on a per-RP/per-(S,G) basis the receipt of    
>      Register-Stop messages from the RPs in the anycast-RP set.
> 
>    o RP1 sends a Register-Stop back to the DR when all RPs in the   
>      Anycast-RP set have returned Register-Stops for a particular
>      (S,G) route.

I think this change pretty much resolve the issue I pointed out about
RP2 possibly losing some packets... And this really render it relevant
to explicitly make RP2 sending register-stop a MUST.

Cheers,

-Thomas

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 11 Apr 2005 10:46:17 -0700

>> somehow duplicates what's in the former.

    Well the intent and my interpretation is that the first paragraph talks
    about if Register-Stops should be sent back. The next bullet talks about
    if the source-tree should be joined or not. So I believe they are two
    separate but related points.

>> to explicitly make RP2 sending register-stop a MUST.

    You might have an old draft copy (I have included the submitted draft 
    below), but the observation section says this:

     an RP. If this is done, the Register-Stop caching option must be
     disabled.

    So I think the latest draft is more clear. Let me know. Thanks.    

Dino

                                                           April 8, 2005

                          Anycast-RP using PIM

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

Copyright Notice

   Copyright (C) The Internet Society (year). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Farinacci, Cai                                                  [Page 1]

Internet Draft            Anycast-RP using PIM             April 8, 2005

Abstract

   This specification allows Anycast-RP (Rendezvous Point) to be used
   inside a domain that runs Protocol Independent Multicast (PIM) only.
   There are no other multicast protocols required to support Anycast-
   RP, such as MSDP, which has been used traditionally to solve this
   problem.

1.0 Introduction

   Anycast-RP as described in [I1] is a mechanism ISP-based backbones
   have used to get fast convergence when a PIM Rendezvous Point (RP)
   router fails. To allow receivers and sources to Rendezvous to the
   closest RP, the packets from a source need to get to all RPs to find
   joined receivers.

1.1 Terminology

2.0 Requirements

   o An IP address is chosen to use as the RP address. This address is
     statically configured, or distributed using a dynamic protocol, to
     all PIM routers throughout the domain.

   o A set of routers in the domain are chosen to act as RPs for this
     RP address. These routers are called the Anycast-RP set.

   o Each router in the Anycast-RP set is configured with a loopback
     interface using the RP address.

   o Each router in the Anycast-RP set also needs a separate IP address,
     to be used for communication between the RPs.

Farinacci, Cai                                                  [Page 2]

Internet Draft            Anycast-RP using PIM             April 8, 2005

   o The RP address, or a prefix that covers the RP address, is injected
     into the unicast routing system inside of the domain.

   o Each router in the Anycast-RP set is configured with the addresses
     of all other routers in the Anycast-RP set. This must be
     consistently configured in all RPs in the set.

Farinacci, Cai                                                  [Page 3]

Internet Draft            Anycast-RP using PIM             April 8, 2005

3.0 Mechanism

   The rules described in this section do not override the rules in
   [N1]. They are intended to blend with the rules in [N1]. If there is
   any question on the interpretation, precedent is given to [N1].

   Note, the address used for the RP address in the domain (the
   Anycast-RP address) needs to be different than the addresses used by
   the Ancyast-RP routers to communicate with each other.

Farinacci, Cai                                                  [Page 4]

Internet Draft            Anycast-RP using PIM             April 8, 2005

   o RP2 sends a Register-Stop back to the RP1. RP2 MAY wait to send the
     Register-Stop if it decides to join the source-tree. RP2 should wait
     until it has received data from the source on the source-tree before
     sending the Register-Stop. If RP2 decides to wait, the Register-Stop
     will be sent when the next Register is received. If RP2 decides not
     to wait, the Register-Stop is sent now.

   o RP1 processes the Register-Stop from each of RP2 and RP3. RP1 MAY
     cache on a per-RP/per-(S,G) basis the receipt of Register-Stop
     messages from the RPs in the anycast-RP set. This option is
     performed to increase the reliablility of Register message delivery
     to each RP. When this option is used, subsequent Register messages
     received by RP1 are sent only to the RPs in the Anycast-RP set
     which have not previously sent Register-Stop messages for the
     (S,G) entry.

   o RP1 sends a Register-Stop back to the DR the next time a Register
     is received from the DR and (when the option in the last bullet
     is in use) if all RPs in the Anycast-RP set have returned
     Register-Stops for a particular (S,G) route.

Farinacci, Cai                                                  [Page 5]

Internet Draft            Anycast-RP using PIM             April 8, 2005

   o An RP will send a copy of a Register only if the Register is received
     from an IP address not in the Anycast-RP list (i.e. the Register
     came from a DR and not another RP). An implementation SHOULD safeguard
     against inconsistently configured anycast-RP sets in each RP by copying
     the TTL from a Register message to the Register messages it copies and
     sends to other RPs.

     an RP. If this is done, the Register-Stop caching option must be
     disabled.

Farinacci, Cai                                                  [Page 6]

Internet Draft            Anycast-RP using PIM             April 8, 2005

Farinacci, Cai                                                  [Page 7]

Internet Draft            Anycast-RP using PIM             April 8, 2005

6.0 IANA Considerations

Farinacci, Cai                                                  [Page 8]

Internet Draft            Anycast-RP using PIM             April 8, 2005

Farinacci, Cai                                                  [Page 9]

Internet Draft            Anycast-RP using PIM             April 8, 2005

8.0 Acknowledgments

9.0 Author Information

   Dino Farinacci
   cisco Systems
   [email-masked]

   Yiqun Cai
   cisco Systems
   [email-masked]

10.0 References

Farinacci, Cai                                                 [Page 10]

Internet Draft            Anycast-RP using PIM             April 8, 2005

Farinacci, Cai                                                 [Page 11]

Internet Draft            Anycast-RP using PIM             April 8, 2005

   Where:

   Example:

   Comment:

Farinacci, Cai                                                 [Page 12]

---

From: MORIN Thomas RD-CORE-LAN <[email-masked]>
Date: Tue, 12 Apr 2005 09:52:16 +0200

Hi Dino,

>     below), but the observation section says this:

Right, I was actually referring to the last version posted to the 
list (April 4th).

>     So I think the latest draft is more clear. Let me know. Thanks. 

After reading it, it is clearer. 
I wouldn't have dubbed the option "register-stop caching" though... 

However, as currently formulated there is a possible
interoperability/configuration issue as two compliant implementations
may end up not interoperating : 
* one implementation suppressing register stops and disabling delayed
register-stops (as proposed in this bullet), 
* one implementation not suppressing register-stops and waiting for all
register-stops being received before register-stopping the DR. 

Depending on how you read the specs, both can be seen as compliant...

I would suggest the following : 
- saying that when the "register-stop caching" option is implemented, it
MUST be possible to turn it off.
- adding "on all RPs in the anycast RP set" at the end of the above
bullet.

Cheers,

-Thomas

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Apr 2005 16:34:03 -0700

>> - adding "on all RPs in the anycast RP set" at the end of the above

    Thanks for the suggestion. But I think register-stop caching will be an
    option that most implementations won't do. I know of two that don't do
    it now.

    So I'm not sure it's worth pulling the spec back into review. The chairs
    can decide.

Dino