| < draft-ietf-mboned-msdp-deploy-05.txt | draft-ietf-mboned-msdp-deploy-06.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT M. McBride | INTERNET-DRAFT M. McBride | |||
| draft-ietf-msdp-deploy-05.txt J. Meylor | J. Meylor | |||
| D. Meyer | D. Meyer | |||
| Category Best Current Practice | Category Best Current Practice | |||
| Expires: July 2004 January 2004 | Expires: September 2004 March 2004 | |||
| Multicast Source Discovery Protocol (MSDP) Deployment Scenarios | Multicast Source Discovery Protocol (MSDP) Deployment Scenarios | |||
| <draft-ietf-mboned-msdp-deploy-05.txt> | <draft-ietf-mboned-msdp-deploy-06.txt> | |||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| Abstract | ||||
| This document describes best current practices for intra-domain and | ||||
| inter-domain deployment of the Multicast Source Discovery Protocol | ||||
| (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode | ||||
| (PIM-SM). | ||||
| Status of this Document | Status of this Document | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 2, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| 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 RFC 2119 [RFC 2119]. | ||||
| This document is a product of the MBONED Working Group. Comments | This document is a product of the MBONED Working Group. Comments | |||
| should be addressed to the authors, or the mailing list at | should be addressed to the authors, or the mailing list at | |||
| mboned@lists.uoregon.edu. | mboned@lists.uoregon.edu. | |||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| Abstract | ||||
| This document describes best current practices for intra-domain and | ||||
| inter-domain deployment of the Multicast Source Discovery Protocol | ||||
| (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode | ||||
| (PIM-SM). | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 5 | 1.1. BCP, Experimental Protocols and Normative References. . . . 5 | |||
| 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 5 | 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 6 | |||
| 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 6 | 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 7 | |||
| 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 8 | 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 8 | |||
| 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 8 | 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 9 | |||
| 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 9 | 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 10 | |||
| 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 9 | 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 10 | |||
| 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 10 | 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 10 | |||
| 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 11 | 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 11 | |||
| 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 11 | 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 12 | |||
| 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 12 | 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 13 | |||
| 4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 13 | 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 14 | |||
| 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 | 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 14 | |||
| 5.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 14 | 4.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 | 4.2. SA message state limits . . . . . . . . . . . . . . . . . . 15 | |||
| 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 | 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 | 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 16 | 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 17 | |||
| 8.2. Informative References. . . . . . . . . . . . . . . . . . . 17 | 7.2. Informative References. . . . . . . . . . . . . . . . . . . 18 | |||
| 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17 | 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 | |||
| 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 19 | ||||
| 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
| 1. Introduction | 1. Introduction | |||
| MSDP [RFC3618] is used primarily in two deployment scenarios: | MSDP [RFC3618] is used primarily in two deployment scenarios: | |||
| o Between PIM Domains | o Between PIM Domains | |||
| MSDP can be used between Protocol Independent Multicast Sparse | MSDP can be used between Protocol Independent Multicast Sparse | |||
| Mode (PIM-SM) [RFC2362] domains to convey information | Mode (PIM-SM) [PIM-SM] domains to convey information | |||
| about active sources available in other domains. MSDP peering | about active sources available in other domains. MSDP peering | |||
| used in such cases is generally one to one peering, and | used in such cases is generally one to one peering, and | |||
| utilizes the deterministic peer-RPF (Reverse Path Forwarding) | utilizes the deterministic peer-RPF (Reverse Path Forwarding) | |||
| rules described in the MSDP specification (i.e., does not use | rules described in the MSDP specification (i.e., does not use | |||
| mesh-groups). Peerings can be aggregated on a single MSDP | mesh-groups). Peerings can be aggregated on a single MSDP | |||
| peer. Such a peer can typically have from one to hundreds of | peer. Such a peer can typically have from one to hundreds of | |||
| peerings, which is similar in scale to BGP peerings. | peerings, which is similar in scale to BGP peerings. | |||
| o Within a PIM Domain | o Within a PIM Domain | |||
| skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 41 ¶ | |||
| one-to-one peering with MSDP peers outside that PIM domain for | one-to-one peering with MSDP peers outside that PIM domain for | |||
| discovery of external sources. MSDP for anycast-RP without | discovery of external sources. MSDP for anycast-RP without | |||
| external MSDP peering is a valid deployment option and common. | external MSDP peering is a valid deployment option and common. | |||
| Current best practice for MSDP deployment utilizes PIM-SM and the | Current best practice for MSDP deployment utilizes PIM-SM and the | |||
| Border Gateway Protocol with multi-protocol extensions (MBGP) | Border Gateway Protocol with multi-protocol extensions (MBGP) | |||
| [RFC1771, RFC2858]. This document outlines how these protocols work | [RFC1771, RFC2858]. This document outlines how these protocols work | |||
| together to provide an intra-domain and inter-domain Any Source | together to provide an intra-domain and inter-domain Any Source | |||
| Multicast (ASM) service. | Multicast (ASM) service. | |||
| Multicast (ASM) service. The PIM-SM specification assumes that SM | The PIM-SM specification assumes that SM operates only in one PIM | |||
| operates only in one PIM domain. MSDP is used to enable the use of | domain. MSDP is used to enable the use of multiple PIM domains by | |||
| multiple PIM domains by distributing the required information about | distributing the required information about active multicast sources | |||
| active multicast sources to other PIM domains. Due to breaking the | to other PIM domains. Due to breaking the Internet multicast | |||
| Internet multicast infrastructure down to multiple PIM domains, MSDP | infrastructure down to multiple PIM domains, MSDP also enables the | |||
| also enables the possibility to set policy on the visibility of the | possibility to set policy on the visibility of the groups and | |||
| groups and sources. | sources. | |||
| Transit IP providers typically deploy MSDP to be part of the global | Transit IP providers typically deploy MSDP to be part of the global | |||
| multicast infrastructure by connecting to their upstream and peer | multicast infrastructure by connecting to their upstream and peer | |||
| multicast networks using MSDP. | multicast networks using MSDP. | |||
| Edge multicast networks typically have two choices: to use their | Edge multicast networks typically have two choices: to use their | |||
| Internet providers RP, or to have their own RP and connect it to | Internet providers RP, or to have their own RP and connect it to | |||
| their ISP using MSDP. By deploying their own RP and MSDP, one can | their ISP using MSDP. By deploying their own RP and MSDP, one can | |||
| use internal multicast groups which are not visible to the provider's | use internal multicast groups which are not visible to the provider's | |||
| RP. This helps with internal multicast being able to continue to work | RP. This helps with internal multicast being able to continue to work | |||
| in the event there is a problem with connectivity to the provider or | in the event there is a problem with connectivity to the provider or | |||
| the provider's RP/MSDP is experiencing difficulties. In the simplest | the provider's RP/MSDP is experiencing difficulties. In the simplest | |||
| cases where no internal multicast groups are necessary, there is | cases where no internal multicast groups are necessary, there is | |||
| often no need to deploy MSDP. | often no need to deploy MSDP. | |||
| 1.1. BCP, Experimental Protocols and Normative References | ||||
| This document describes the best current practice for a widely | ||||
| deployed Experimental protocol, MSDP. There is no plan to advance the | ||||
| MSDP's status (for example, to Proposed Standard). The reasons for | ||||
| this include: | ||||
| o MSDP was originally envisioned as a temporary protocol to be | ||||
| supplanted by whatever the IDMR working group produced as an | ||||
| inter-domain protocol. However, the IDMR WG (or subsequently, | ||||
| the BGMP WG) never produced a protocol that could be deployed | ||||
| to replace MSDP. | ||||
| o One of the primary reasons given for MSDP to be classified as | ||||
| Experimental was that the MSDP Working Group came up with | ||||
| modifications to the protocol that the WG thought made it | ||||
| better but that implementors didn't see any reasons to | ||||
| deploy. Without these modifications (e.g., UDP or GRE | ||||
| encapsulation), MSDP can have negative consequences to initial | ||||
| packets in datagram streams. | ||||
| o Scalability: Although we don't know what the hard limits might | ||||
| be, readvertising everything you know every 60 seconds clearly | ||||
| limits the amount of state you can advertise. | ||||
| o MSDP reached near ubiquitous deployment as the de-facto | ||||
| standard inter-domain multicast protocol in the IPv4 Internet. | ||||
| o No consensus could be reached regarding the reworking of MSDP | ||||
| to address the many concerns of various constituencies within | ||||
| the IETF. As a result, a decision was taken to document what is | ||||
| (ubiquitously) deployed and move that document to Experimental. | ||||
| While advancement of MSDP to Proposed Standard was considered, | ||||
| for the reasons mentioned above, it was immediately discarded. | ||||
| o The advent of protocols such as source specific multicast and | ||||
| bi-directional PIM, as well as embedded RP techniques for | ||||
| IPv6, have further reduced consensus that a replacement | ||||
| protocol for MSDP for the IPv4 Internet is required. | ||||
| The RFC Editor's policy regarding references is that they be split | ||||
| into two categories known as "normative" and "informative". Normative | ||||
| references specify those documents which must be read to understand | ||||
| or implement the technology in an RFC (or whose technology must be | ||||
| present for the technology in the new RFC to work) [RFCED]. In order | ||||
| to understand this document, one must also understand both the PIM | ||||
| and MSDP documents. As a result, references to these documents are | ||||
| normative. | ||||
| The IETF has adopted the policy that BCPs must not have normative | ||||
| references to Experimental protocols. However, this document is a | ||||
| special case in that the underlying Experimental document (MSDP) is | ||||
| not planned to be advanced to Proposed Standard. | ||||
| The MBONED Working Group requests approval under the Variance | ||||
| Procedure as documented in RFC 2026 [RFC2026]. | ||||
| Note to RFC-Editor: If IETF/IESG approves this, please change the | ||||
| above sentence into: The MBONED Working Group has requested approval | ||||
| under the Variance Procedure as documented in RFC 2026 [RFC2026]. | ||||
| The IESG followed the Variance Procedure, and after an additional 4 | ||||
| week IETF Last Call evaluated the comments and status and has | ||||
| approved this document. | ||||
| 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 RFC 2119 [RFC 2119]. | ||||
| 2. Inter-domain MSDP Peering Scenarios | 2. Inter-domain MSDP Peering Scenarios | |||
| The following sections describe the most common inter-domain MSDP | The following sections describe the most common inter-domain MSDP | |||
| peering possibilities and their deployment options. | peering possibilities and their deployment options. | |||
| 2.1. Peering between PIM Border Routers | 2.1. Peering between PIM Border Routers | |||
| In this case, the MSDP peers within the domain have their own RP | In this case, the MSDP peers within the domain have their own RP | |||
| located within a bounded PIM domain. In addition, the domain will | located within a bounded PIM domain. In addition, the domain will | |||
| typically have its own Autonomous System (AS) number and one or more | typically have its own Autonomous System (AS) number and one or more | |||
| skipping to change at page 13, line 18 ¶ | skipping to change at page 14, line 38 ¶ | |||
| address either through Auto-RP, BSR, or a static RP assignment. Each | address either through Auto-RP, BSR, or a static RP assignment. Each | |||
| designated router in the domain will send source registers and group | designated router in the domain will send source registers and group | |||
| joins to the Anycast RP address. Unicast routing will direct those | joins to the Anycast RP address. Unicast routing will direct those | |||
| registers and joins to the nearest Anycast RP. If a particular | registers and joins to the nearest Anycast RP. If a particular | |||
| Anycast RP router fails, unicast routing will direct subsequent | Anycast RP router fails, unicast routing will direct subsequent | |||
| registers and joins to the nearest Anycast RP. That RP will then | registers and joins to the nearest Anycast RP. That RP will then | |||
| forward an MSDP update to all peers within the Anycast MSDP mesh | forward an MSDP update to all peers within the Anycast MSDP mesh | |||
| group. Each RP will then forward (or receive) the SAs to (from) | group. Each RP will then forward (or receive) the SAs to (from) | |||
| external customers and providers. | external customers and providers. | |||
| 4. Intellectual Property | 4. Security Considerations | |||
| The IETF takes no position regarding the validity or scope of any | ||||
| intellectual property or other rights that might be claimed to | ||||
| pertain to the implementation or use of the technology described in | ||||
| this document or the extent to which any license under such rights | ||||
| might or might not be available; neither does it represent that it | ||||
| has made any effort to identify any such rights. Information on the | ||||
| IETF's procedures with respect to rights in standards-track and | ||||
| standards-related documentation can be found in BCP-11. Copies of | ||||
| claims of rights made available for publication and any assurances of | ||||
| licenses to be made available, or the result of an attempt made to | ||||
| obtain a general license or permission for the use of such | ||||
| proprietary rights by implementors or users of this specification can | ||||
| be obtained from the IETF Secretariat. | ||||
| The IETF invites any interested party to bring to its attention any | ||||
| copyrights, patents or patent applications, or other proprietary | ||||
| rights which may cover technology that may be required to practice | ||||
| this standard. Please address the information to the IETF Executive | ||||
| Director. | ||||
| 5. Security Considerations | ||||
| An MSDP service should be secured by explicitly controlling the state | An MSDP service should be secured by explicitly controlling the state | |||
| which is created by, and passed within, the MSDP service. As with | which is created by, and passed within, the MSDP service. As with | |||
| unicast routing state, MSDP state should be controlled locally, at | unicast routing state, MSDP state should be controlled locally, at | |||
| the edge origination points. Selective filtering at the multicast | the edge origination points. Selective filtering at the multicast | |||
| service edge helps ensure that only intended sources result in SA | service edge helps ensure that only intended sources result in SA | |||
| message creation, and this control helps to reduce the likelihood of | message creation, and this control helps to reduce the likelihood of | |||
| state-aggregation related problems in the core. There are a variety | state-aggregation related problems in the core. There are a variety | |||
| of points where local policy should be applied to the MSDP service. | of points where local policy should be applied to the MSDP service. | |||
| 5.1. Filtering SA messages | 4.1. Filtering SA messages | |||
| The process of originating SA messages should be filtered to ensure | The process of originating SA messages should be filtered to ensure | |||
| only intended local sources are resulting in SA message origination. | only intended local sources are resulting in SA message origination. | |||
| In addition, MSDP speakers should filter on which SA messages get | In addition, MSDP speakers should filter on which SA messages get | |||
| received and forwarded. | received and forwarded. | |||
| Typically there is a fair amount of (S,G) state in a PIM-SM domain | Typically there is a fair amount of (S,G) state in a PIM-SM domain | |||
| that is local to the domain. However, without proper filtering, sa- | that is local to the domain. However, without proper filtering, sa- | |||
| messages containing these local (S,G) announcements may be advertised | messages containing these local (S,G) announcements may be advertised | |||
| to the global MSDP infrastructure. Examples of this includes domain | to the global MSDP infrastructure. Examples of this includes domain | |||
| local applications that use global IP multicast addresses and sources | local applications that use global IP multicast addresses and sources | |||
| that use RFC 1918 addresses [RFC1918]. To improve on the scalability | that use RFC 1918 addresses [RFC1918]. To improve on the scalability | |||
| of MSDP and to avoid global visibility of domain local (S,G) | of MSDP and to avoid global visibility of domain local (S,G) | |||
| information, an external SA filter list is recommended to help | information, an external SA filter list is recommended to help | |||
| prevent unnecessary creation, forwarding, and caching of well-known | prevent unnecessary creation, forwarding, and caching of well-known | |||
| domain local sources. | domain local sources. | |||
| 5.2. SA message state limits | 4.2. SA message state limits | |||
| Proper filtering on SA message origination, receipt, and forwarding | Proper filtering on SA message origination, receipt, and forwarding | |||
| will significantly reduce the likelihood of unintended and unexpected | will significantly reduce the likelihood of unintended and unexpected | |||
| spikes in MSDP state However, a sa-cache state limit SHOULD BE | spikes in MSDP state However, a sa-cache state limit SHOULD be | |||
| configured as a final safeguard to state spikes. When an MSDP peering | configured as a final safeguard to state spikes. When an MSDP peering | |||
| has reached a stable state (i.e., when the peering has been | has reached a stable state (i.e., when the peering has been | |||
| established and the initial SA state has been transferred), it may | established and the initial SA state has been transferred), it may | |||
| also be desirable to configure a rate limiter for the creation of new | also be desirable to configure a rate limiter for the creation of new | |||
| SA state entries. | SA state entries. | |||
| 6. IANA Considerations | 5. IANA Considerations | |||
| This document creates a no new requirements on IANA namespaces | ||||
| This document creates no new requirements on IANA namespaces | ||||
| [RFC2434]. | [RFC2434]. | |||
| 7. Acknowledgments | 6. Acknowledgments | |||
| The authors would like to thank Pekka Savola, John Zwiebel, Swapna | The authors would like to thank Pekka Savola, John Zwiebel, Swapna | |||
| Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier | Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier | |||
| versions of this document. | versions of this document. | |||
| 8. References | 7. References | |||
| 8.1. Normative References | 7.1. Normative References | |||
| [PIM-SM] Fenner, B., et. al, "Protocol Independent Multicast - | ||||
| Sparse Mode (PIM-SM): Protocol Specification | ||||
| (Revised)", draft-ietf-pim-sm-v2-new-09.txt. Work | ||||
| in progress. | ||||
| [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway | [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway | |||
| Protocol 4 (BGP-4)", RFC 1771, March 1995. | Protocol 4 (BGP-4)", RFC 1771, March 1995. | |||
| [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de | [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de | |||
| Groot, E. Lear, "Address Allocation for Private | Groot, E. Lear, "Address Allocation for Private | |||
| Internets", RFC 1918, Feburary, 1996. | Internets", RFC 1918, Feburary, 1996. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to | [RFC2119] Bradner, S., "Key words for use in RFCs to | |||
| Indicate Requirement Levels" RFC 2119/BCP 14, | Indicate Requirement Levels" RFC 2119/BCP 14, | |||
| March 1997. | March 1997. | |||
| [RFC2362] D. Estrin, et. al., "Protocol Independent | ||||
| Multicast - Sparse Mode (PIM-SM): Protocol | ||||
| Specification", RFC 2362, June, 1998. | ||||
| [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", | [RFC2365] Meyer, D. "Administratively Scoped IP Multicast", | |||
| RFC 2365, July, 1998. | RFC 2365, July, 1998. | |||
| [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for | [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for | |||
| Writing an IANA Considerations Section in | Writing an IANA Considerations Section in | |||
| RFCs", RFC 2434/BCP 0026, October, 1998. | RFCs", RFC 2434/BCP 0026, October, 1998. | |||
| [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, | [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, | |||
| "Multiprotocol Extensions for BGP-4", RFC 2858, | "Multiprotocol Extensions for BGP-4", RFC 2858, | |||
| June 2000. | June 2000. | |||
| skipping to change at page 17, line 5 ¶ | skipping to change at page 18, line 5 ¶ | |||
| [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) | [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) | |||
| Mechanism using Protocol Independent Multicast | Mechanism using Protocol Independent Multicast | |||
| (PIM) and Multicast Source Discovery Protocol | (PIM) and Multicast Source Discovery Protocol | |||
| (MSDP)", RFC 3446, January, 2003. | (MSDP)", RFC 3446, January, 2003. | |||
| [RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast | [RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast | |||
| Source Discovery Protocol (MSDP)", RFC 3618, | Source Discovery Protocol (MSDP)", RFC 3618, | |||
| October, 2003. | October, 2003. | |||
| 8.2. Informative References | 7.2. Informative References | |||
| [AUTORP] Fenner, W., et. al., " Protocol Independent | [AUTORP] Fenner, W., et. al., " Protocol Independent | |||
| Multicast - Sparse Mode (PIM-SM): Protocol | Multicast - Sparse Mode (PIM-SM): Protocol | |||
| Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt, | Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt, | |||
| April, 2004. Work in progress. | April, 2004. Work in progress. | |||
| [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) | [BSR] Fenner, W., et. al., "Bootstrap Router (BSR) | |||
| Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, | Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, | |||
| February, 2003. Work in progress. | February, 2003. Work in progress. | |||
| [IANA] http://www.iana.org | [IANA] http://www.iana.org | |||
| 9. Author's Addresses | [RFCED] http://www.rfc-editor.org/policy.html#policy.refs | |||
| 8. Author's Addresses | ||||
| Mike McBride | Mike McBride | |||
| Cisco Systems | Cisco Systems | |||
| Email: mcbride@cisco.com | Email: mcbride@cisco.com | |||
| John Meylor | John Meylor | |||
| Cisco Systems | Cisco Systems | |||
| Email: jmeylor@cisco.com | Email: jmeylor@cisco.com | |||
| David Meyer | David Meyer | |||
| Email: dmm@1-4-5.net | Email: dmm@1-4-5.net | |||
| 10. Full Copyright Statement | 9. Full Copyright Statement | |||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
| others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
| or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
| and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
| kind, provided that the above copyright notice and this paragraph are | kind, provided that the above copyright notice and this paragraph are | |||
| included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
| document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
| the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
| Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
| skipping to change at line 644 ¶ | skipping to change at page 19, line 20 ¶ | |||
| The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
| revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
| This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| 10. Intellectual Property | ||||
| The IETF takes no position regarding the validity or scope of any | ||||
| Intellectual Property Rights or other rights that might be claimed to | ||||
| pertain to the implementation or use of the technology described in | ||||
| this document or the extent to which any license under such rights | ||||
| might or might not be available; nor does it represent that it has | ||||
| made any independent effort to identify any such rights. Information | ||||
| on the procedures with respect to rights in RFC documents can be | ||||
| found in BCP 78 and BCP 79. | ||||
| Copies of IPR disclosures made to the IETF Secretariat and any | ||||
| assurances of licenses to be made available, or the result of an | ||||
| attempt made to obtain a general license or permission for the use of | ||||
| such proprietary rights by implementers or users of this | ||||
| specification can be obtained from the IETF on-line IPR repository at | ||||
| http://www.ietf.org/ipr. | ||||
| The IETF invites any interested party to bring to its attention any | ||||
| copyrights, patents or patent applications, or other proprietary | ||||
| rights that may cover technology that may be required to implement | ||||
| this standard. Please address the information to the IETF at ietf- | ||||
| ipr@ietf.org. | ||||
| 11. Acknowledgement | ||||
| Funding for the RFC Editor function is currently provided by the | ||||
| Internet Society. | ||||
| End of changes. 24 change blocks. | ||||
| 88 lines changed or deleted | 136 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||