draft-ietf-mboned-interdomain-peering-bcp-13.txt   draft-ietf-mboned-interdomain-peering-bcp-14.txt 
MBONED Working Group P. Tarapore, Ed. MBONED Working Group P. Tarapore, Ed.
Internet-Draft R. Sayko Internet-Draft R. Sayko
Intended status: Best Current Practice AT&T Intended status: Best Current Practice AT&T
Expires: April 30, 2018 G. Shepherd Expires: May 3, 2018 G. Shepherd
Cisco Cisco
T. Eckert, Ed. T. Eckert, Ed.
Huawei Huawei
R. Krishnan R. Krishnan
SupportVectors SupportVectors
October 27, 2017 October 30, 2017
Use of Multicast Across Inter-Domain Peering Points Use of Multicast Across Inter-Domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-13 draft-ietf-mboned-interdomain-peering-bcp-14
Abstract Abstract
This document examines the use of Source Specific Multicast (SSM) This document examines the use of Source Specific Multicast (SSM)
across inter-domain peering points for a specified set of deployment across inter-domain peering points for a specified set of deployment
scenarios. The objective is to describe the setup process for scenarios. The objective is to describe the setup process for
multicast-based delivery across administrative domains for these multicast-based delivery across administrative domains for these
scenarios and document supporting functionality to enable this scenarios and document supporting functionality to enable this
process. process.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 30, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 11 skipping to change at page 8, line 11
the scope of this document. the scope of this document.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
a. Dual homing for peering points between domains is recommended as a. Dual homing for peering points between domains is recommended as
a way to ensure reliability with full BGP table visibility. a way to ensure reliability with full BGP table visibility.
b. If the peering point between AD-1 and AD-2 is a controlled b. If the peering point between AD-1 and AD-2 is a controlled
network environment, then bandwidth can be allocated accordingly network environment, then bandwidth can be allocated accordingly
by the two domains to permit the transit of non- rate adaptive by the two domains to permit the transit of non- rate adaptive
multicast traffic. If this is not the case, then it is multicast traffic. If this is not the case, then the multicast
recommended that the multicast traffic should support rate- traffic must support rate-adaption (see [BCP145]).
adaption.
c. The sending and receiving of multicast traffic between two c. The sending and receiving of multicast traffic between two
domains is typically determined by local policies associated with domains is typically determined by local policies associated with
each domain. For example, if AD-1 is a service provider and AD-2 each domain. For example, if AD-1 is a service provider and AD-2
is an enterprise, then AD-1 may support local policies for is an enterprise, then AD-1 may support local policies for
traffic delivery to, but not traffic reception from, AD-2. traffic delivery to, but not traffic reception from, AD-2.
Another example is the use of a policy by which AD-1 delivers Another example is the use of a policy by which AD-1 delivers
specified content to AD-2 only if such delivery has been accepted specified content to AD-2 only if such delivery has been accepted
by contract. by contract.
skipping to change at page 37, line 41 skipping to change at page 37, line 41
Joel Jaeggli Joel Jaeggli
Albert Manfredi Albert Manfredi
Stig Venaas Stig Venaas
Henrik Levkowetz Henrik Levkowetz
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
Please see discussion on mailing list for changes before -111. Please see discussion on mailing list for changes before -11.
-11: version in IESG review. -11: version in IESG review.
-12: XML'ified version of -11, committed solely to make rfcdiff -12: XML'ified version of -11, committed solely to make rfcdiff
easier. XML versions hosted on https://www.github.com/toerless/ easier. XML versions hosted on https://www.github.com/toerless/
peering-bcp peering-bcp
-13: -13:
o IESG feedback. Complete details in: o IESG feedback. Complete details in:
skipping to change at page 39, line 18 skipping to change at page 39, line 18
o Spencer Dawkins: Various editorial fixes. Removed BCP38 text from o Spencer Dawkins: Various editorial fixes. Removed BCP38 text from
section 3, superceeded be explanation of PIM-SM RPF check to section 3, superceeded be explanation of PIM-SM RPF check to
provide equvialent security to BCP38 in security section 7.1). provide equvialent security to BCP38 in security section 7.1).
o Eric Roscorla: (fixed from other reviews already). o Eric Roscorla: (fixed from other reviews already).
o Adam Roach: Fixed up text about MDH-04, added reference to o Adam Roach: Fixed up text about MDH-04, added reference to
RFC4786. RFC4786.
-13: Fix for Mirja's review on must for congestion control.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
 End of changes. 7 change blocks. 
8 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/