draft-ietf-bgmp-spec-04.txt   draft-ietf-bgmp-spec-05.txt 
BGMP Working Group D. Thaler BGMP Working Group D. Thaler
Internet Engineering Task Force Microsoft Internet Engineering Task Force Microsoft
Expires October 2003 Expires November 2003
Border Gateway Multicast Protocol (BGMP): Border Gateway Multicast Protocol (BGMP):
Protocol Specification Protocol Specification
<draft-ietf-bgmp-spec-04.txt> <draft-ietf-bgmp-spec-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
with a single root (in BGMP it is referred to as the root domain). It with a single root (in BGMP it is referred to as the root domain). It
requires that different ranges of the class D space are associated requires that different ranges of the class D space are associated
(e.g., with Unicast-Prefix-Based Multicast addressing) with different (e.g., with Unicast-Prefix-Based Multicast addressing) with different
domains. Each of these domains then becomes the root of the shared domains. Each of these domains then becomes the root of the shared
domain-trees for all groups in its range. Multicast participants will domain-trees for all groups in its range. Multicast participants will
generally receive better multicast service if the session initiator's generally receive better multicast service if the session initiator's
address allocator selects addresses from its own domain's part of the address allocator selects addresses from its own domain's part of the
space, thereby causing the root domain to be local to at least one of space, thereby causing the root domain to be local to at least one of
the session participants. the session participants.
NOTE:
This specification is published for the general information of the
Internet technical community and as an archival record of the work
done. The operational community generally agrees that this protocol
is not deployable in its current form; it is being published in the
hopes that it may provide a useful starting point for future work.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
1. Acknowledgements 1. Acknowledgements
In addition to the editors, the following individuals have In addition to the editors, the following individuals have
contributed to the design of BGMP: Cengiz Alaettinoglu, Tony contributed to the design of BGMP: Cengiz Alaettinoglu, Tony
Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino
Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave
Meyer, and Satish Kumar. Meyer, and Satish Kumar.
This document is the product of the IETF BGMP Working Group with Dave This document is the product of the IETF BGMP Working Group with Dave
skipping to change at page 3, line 41 skipping to change at page 3, line 41
They then send incremental Join/Prune Updates as group memberships They then send incremental Join/Prune Updates as group memberships
change. BGMP does not require periodic refresh of individual change. BGMP does not require periodic refresh of individual
entries. KeepAlive messages are sent periodically to ensure the entries. KeepAlive messages are sent periodically to ensure the
liveness of the connection. Notification messages are sent in liveness of the connection. Notification messages are sent in
response to errors or special conditions. If a connection encounters response to errors or special conditions. If a connection encounters
an error condition, a notification message is sent and the connection an error condition, a notification message is sent and the connection
is closed if the error is a fatal one. is closed if the error is a fatal one.
3. Revision History 3. Revision History
29 May 2003 draft-01 29 June 2003 draft-01
(1) Removed all references to MASC and G-RIB. The current spec only (1) Removed all references to MASC and G-RIB. The current spec only
covers BGMP operation for source-specific groups, and any-source- covers BGMP operation for source-specific groups, and any-source-
multicast using unicast prefix-based multicast addresses (for multicast using unicast prefix-based multicast addresses (for
both IPv4 and IPv6). No new routes of any type are needed in the both IPv4 and IPv6). No new routes of any type are needed in the
routing table. routing table.
(2) Removed section on transitioning away from using DVMRP as the (2) Removed section on transitioning away from using DVMRP as the
backbone to an AS-based multicast routing system with MBGP, as backbone to an AS-based multicast routing system with MBGP, as
this has already happened. this has already happened.
 End of changes. 5 change blocks. 
4 lines changed or deleted 11 lines changed or added

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