Re: [[e-mail]: Re: [pim] What's the definition of "quick turnaround"?]

[Tom Pusateri <[e-mail]>]

I'm good. Make sure you follow the new ID rules or it will bounce back to you.

Tom

In message <[e-mail]> you write:
>    Anyone see any objections with progressing this draft now? I'd like to hea
>r
>    from both the chairs and area directors before submitting the draft.
>
>    I have again enclosed the spec after Thomas' email.
>
>    I assume:
>
>    1) We are passed last call (already have had 3 of them).
>    2) There should be no objections by Bill. He indicated in the working grou
>p
>       that this can be progressed if there were minor changes.
>    3) The people who were vocal are now happy with the changes (Amit, Tom,
>       and Thomas).
>
>Thanks,
>Dino
>
>------------------------------------------------------------------------------
>-
>
>------- Start of forwarded message -------
>X-BrightmailFiltered: true
>X-Brightmail-Tracker: AAAAAA==
>X-IronPort-AV: i="3.96,115,1122879600"; 
>   d="scan'208"; a="106801641:sNHT14338676"
>Subject: Re: [pim] What's the definition of "quick turnaround"?
>From: Thomas Morin <[e-mail]>
>To: Dino Farinacci <[e-mail]>
>In-Reply-To: <[e-mail]>
>Content-Type: text/plain
>Organization: France Telecom R&D
>Date: Wed, 17 Aug 2005 09:41:47 +0200
>X-OriginalArrivalTime: 17 Aug 2005 07:41:44.0711 (UTC) FILETIME=[1D9CE970:01C5
>A2FF]
>X-PMX-Version: 4.7.1.128075
>X-from-outside-Cisco: 128.107.243.14
>
>Hi Dino,
>
>Dino Farinacci :
>> >> >     I am afraid if we mention it, we are telling the reader that packet
> loss
>> >> >     is intentionally designed in and we are condoning it. Sometimes it'
>s 
>> >> >     better not to say anything.
>> >> 
>> >> I think such imperfections should still be documented somewhere.
>> 
>>     Let me know what you think of of the enclosed text. I aded a new bullet
>>     earlier in the procedure about when RP1 sends a Register-Stop as well as
>>     an observation about state loss in the other RPs when Registers could
>>     be lost.
>
>I thinks that these new paragraphs makes the points we discussed clearer
>now. Thank you.
>
>>     Since Amit is happy with the text I sent yesterday (which is included
>>     below) and if Thomas agrees to the text below, [...]
>
>I do.
>
>Cheers,
>
>- -Thomas
>------- End of forwarded message -------
>
>------------------------------------------------------------------------------
>-
>
>Network Working Group                                     Dino Farinacci
>INTERNET-DRAFT                                                 Yiqun Cai
>Expiration Date: March 2006                                cisco Systems
>                                                         August 16, 2005
>
>
>                          Anycast-RP using PIM
>                   <draft-ietf-pim-anycast-rp-04.txt>
>
>
>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.
>
>   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/1id-abstracts.html
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.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           August 16, 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.
>
>   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 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           August 16, 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           August 16, 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.
>
>   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].
>
>
>         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 S3 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 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 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.
>
>   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.
>
>
>
>Farinacci, Cai                                                  [Page 4]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>   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 RP1 sends a Register-Stop back to the DR. If, for some reason,
>     the Register messages to RP2 and RP3 are lost, then when the
>     Register suppression timer expires in the DR, it will resend
>     Registers to allow another chance for all RPs in the Anycast-RP
>     set to obtain the (S,G) state.
>
>   o RP2 receives the Register message from RP1, decapsulates it, and
>     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, 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 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. There
>     is no specific action taken when processing Register-Stop messages.
>
>   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 copying
>
>
>
>Farinacci, Cai                                                  [Page 5]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>     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.
>
>   o Packets flow to all receivers no matter what RP they have joined 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.
>
>   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 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.
>
>   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.
>
>   o Since the RP, who receives a Register from the DR, will send copies
>     of the Register to the other RPs at the same time it sends a
>     Register-Stop to the DR, there could be packet loss and lost state
>     in the other RPs until the time the DR sends Register messages again.
>
>
>
>Farinacci, Cai                                                  [Page 6]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>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
>   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.
>
>
>
>
>Farinacci, Cai                                                  [Page 7]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>   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.
>
>   The amount of Register traffic generated by this MSDP-peering RP
>   would be equal to the number of active sources external to the
>   domain. The Source-Active state would have to be conveyed to all
>   other RPs in the Anycast-RP set since the MSDP-peering RP would not
>   know about the group membership associated with the other RPs. To
>   avoid this periodic control traffic, it is recommended that all
>   Anycast-RPs be configured with external MSDP peering sessions so no
>   RP in the Anycast-RP set will have to originate Register messages on
>   behalf of external sources.
>
>
>
>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
>
>
>
>Farinacci, Cai                                                  [Page 8]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>   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
>   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 9]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 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)
>      Amit Shukla (Juniper Networks)
>      Tom Pusateri (Juniper Networks)
>
>
>9.0 Author Information
>
>   Dino Farinacci
>   cisco Systems
>   [e-mail]
>
>   Yiqun Cai
>   cisco Systems
>   [e-mail]
>
>
>
>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.
>
>
>
>
>Farinacci, Cai                                                 [Page 10]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 2005
>
>
>10.2 Informative References
>
>   [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 11]
>
>
>
>
>
>Internet Draft            Anycast-RP using PIM           August 16, 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 12]
>
>------------------------------------------------------------------------------
>-
>
>_______________________________________________
>pim mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/pim

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