Re: Document Action: 'Border Gateway Multicast Protocol (BGMP): Protocol Specification' to Informational RFC

>The IESG has approved the following document:
>
>- 'Border Gateway Multicast Protocol (BGMP): Protocol Specification '
>   <draft-ietf-bgmp-spec-06.txt> as an Informational RFC

That completes the BGMP working group's goals -- to publish the BGMP
spec as a snapshot of the work that was done.  Thanks to everyone who
participated in this effort!  Here's to future interest in BGMP =)

Alex, please close the working group.

Thanks,
  Bill

Document Action: 'Border Gateway Multicast Protocol (BGMP): Protocol Specification' to Informational RFC

The IESG has approved the following document:

- 'Border Gateway Multicast Protocol (BGMP): Protocol Specification '
   <draft-ietf-bgmp-spec-06.txt> as an Informational RFC

This document is the product of the Border Gateway Multicast Protocol 
Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary

 This document describes BGMP, a protocol for inter-domain multicast
 routing.  BGMP builds shared trees for active multicast groups, and
 optionally allows receiver domains to build source-specific, inter-
 domain, distribution branches where needed.  BGMP natively supports
 "source-specific multicast" (SSM).  To also support "any-source
 multicast" (ASM), BGMP requires that each multicast group be associated
 with a single root (in BGMP it is referred to as the root domain).  It
 requires that different ranges of the multicast address space are
 associated (e.g., with Unicast-Prefix-Based Multicast addressing) with
 different domains.  Each of these domains then becomes the root of the
 shared domain-trees for all groups in its range.  Multicast participants
 will generally receive better multicast service if the session
 initiator's 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 the session participants.

Working Group Summary

Fax Message Received

SSL VPN Conference

unscribe this maillist

unscribe this maillist, thank you.

RE: Note for draft-ietf-bgmp-spec

I just now re-read RFC 2026 sections 4.2.1 and 4.2.2 and believe
that Experimental is more in the spirit of the text of the NOTE
you propose (which I have no problem with).

The same reason below also applies to other protocols, such as
the original PIM-SM and MASC, which both went to Experimental
instead of Informational.

-Dave

> -----Original Message-----
> From: Bill Fenner [mailto:fenner <at> research.att.com]
> Sent: Thursday, February 12, 2004 3:02 PM
> To: bgmp <at> ietf.org
> Cc: Dave Thaler
> Subject: Note for draft-ietf-bgmp-spec
> 
> 
> Folks,
> 
>   The IESG approved draft-ietf-bgmp-spec, with a request for a note
> describing why it's going for informational instead of standards
track.
> I drafted the following; comments are appreciated.
> 
> 
> NOTE:
>   This specification is published for the general information of the
>   Internet technical community and as an archival record of the work
>   done.  Although the working group had consensus on this document,
>   there was insufficient interest from the operational and vendor
>   community to develop an implementation, which is a requirement for
>   a routing protocol to enter the standards track.
> 
> 
> Thanks,
>   Bill

Note for draft-ietf-bgmp-spec

Folks,

  The IESG approved draft-ietf-bgmp-spec, with a request for a note
describing why it's going for informational instead of standards track.
I drafted the following; comments are appreciated.

NOTE:
  This specification is published for the general information of the
  Internet technical community and as an archival record of the work
  done.  Although the working group had consensus on this document,
  there was insufficient interest from the operational and vendor
  community to develop an implementation, which is a requirement for
  a routing protocol to enter the standards track.

Thanks,
  Bill

I-D ACTION:draft-ietf-bgmp-spec-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Border Gateway Multicast Protocol Working Group of the IETF.

	Title		: Border Gateway Multicast Protocol (BGMP): Protocol Specification
	Author(s)	: D. Thaler
	Filename	: draft-ietf-bgmp-spec-06.txt
	Pages		: 45
	Date		: 2004-1-20
	
This document describes BGMP, a protocol for inter-domain multicast
routing.  BGMP builds shared trees for active multicast groups, and
optionally allows receiver domains to build source-specific, inter-
domain, distribution branches where needed.  BGMP natively supports
'source-specific multicast' (SSM).  To also support 'any-source
multicast' (ASM), BGMP requires that each multicast group be associated
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
(e.g., with Unicast-Prefix-Based Multicast addressing) with different
domains.  Each of these domains then becomes the root of the shared
domain-trees for all groups in its range.  Multicast participants will
generally receive better multicast service if the session initiator's
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
the session participants.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bgmp-spec-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-bgmp-spec-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-bgmp-spec-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Moving the BGMP mailing list

All,

The mailing list of the IETF BGMP working group
would be moved from its current location to the IETF site.
The new address of the list would be:

bgmp at ietf.org

I will automatically subscribe all current members so you don't need
to do anything. Everyone subscribed to the new mailing list would
receive an automated message. If you don't receive such message,
then please let me know.

If you want to unsubscribe from the new list, you can use its WEB
interface:

http://www1.ietf.org/mailman/listinfo/bgmp/

Shortly I will disable the old list and will update the web page
(http://netweb.usc.edu/bgmp/) to point to the new address.

For the time being all the email sent to the old address will be
redirected to the new address, but the redirected email will be
delayed for administrative approval. Hence, this redirection may be
cut-off in the future.

If you need any administrative assistance with your membership,
please send an email to the administrative contact listed at the
bottom of the web page of the new mailing list.

Thank You,
Pavlin

Re: A note in draft-ietf-bgmp-spec-05.txt

Pavlin,

  Thanks for pointing that out.  I guess the comment addition was
out of phase with the state of the document -- the G-RIB was the
real problem that nobody liked as far as I can remember.  You're
right that there's no writeup of what's wrong; I don't think anyone
who pointed out problems has revisited the architecture since the
removal of the G-RIB.

  Bill

A note in draft-ietf-bgmp-spec-05.txt

Dave (and everybody else who may have info on the subject),

I was looking into the difference between version 04 and 05 of
the BGMP I-D, and the difference is the following note (right after
the abstract) that has been added to version 05:

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.

I'd like to know what are the deployment issues in BGMP the
operational community has pointed out (e.g., is there a published
document that describes the issues), and when/where this agreement
has been reached.

Thanks,
Pavlin