Subject: mboned: I-D ACTION:draft-ietf-mboned-routingarch-00.txt

From: [email-masked]
Date: Wed, 27 Apr 2005 09:53:48 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment Working Group of the IETF.

	Title		: Overview of the Internet Multicast Routing Architecture
	Author(s)	: P. Savola
	Filename	: draft-ietf-mboned-routingarch-00.txt
	Pages		: 20
	Date		: 2005-4-26
	
The lack of up-to-date documentation on IP multicast routing
   protocols and procedures has caused a great deal of confusion.  To
   clarify the situation, this memo describes the routing protocols and
   techniques currently (as of this writing) in use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-mboned-routingarch-00.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mboned-routingarch-00.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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Apr 2005 10:08:33 +0300 (EEST)

Folks,

This new -00 version basically just includes updates in Section 2.1, 
to address Tom's concerns about badly portraying (in particular) 
MOSPF.

I'd encourage the other WG members to take a look especially at 
Section 2.1 and see if they feel comfortable with it.

I also made some minor edits, like clarified IGMP proxying and removed 
MSNIP.

The document also has a couple of XXX's, and I'd like to solicit 
text/suggestions from the WG participånts particularly on the two of 
them:

[Bi-directional PIM]
    As of this writing, it cannot be applied in Inter-domain multicast or
    for Embedded-RP.  XXX: explain why not, someone send text? (one
    paragraph please!).

[Bi-directional PIM]
    Bi-directional PIM (see Section 2.1.3) was designed with faster
    multicast convergence in mind, and if fast failover is required, it
    may seem like an attractive solution.

    XXX: someone want to send a bit more text about the convergence
    differences wrt PIM-SM?

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 Apr 2005 00:40:51 -0700

>>     may seem like an attractive solution.

    I would argue that DF-election is slower than RPF which is used in ASM 
    and SSM. Since both DF-election and RPF are triggered by a unicast routing
    table change, the former requires multiple packet exchanges on all LAN 
    interfaces before convergence is achieved where the later is just an 
    internal router change to the multicast routing table entries.

Dino
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 28 Apr 2005 09:13:52 -0400

On Thu, 28 Apr 2005 10:08:33 +0300 (EEST)
>     for Embedded-RP.  XXX: explain why not, someone send text? (one

For Inter-domain IPv4, the answer is clear :

Bi-directional PIM (draft-ietf-pim-bidir-07.txt)sets up a 
shared multicast distribution tree for a range
of multicast groups, with a specific Rendezvous Point Address (RPA)
serving as the root of the distribution
tree for the multicast group range, and all PIM joins and leaves
in that group range being (*,G) group specific joins and leaves. 
Since inter-domain IPv4 multicast only passes (S,G) joins and leaves through domain
boundaries, BiDir-PIM will not propagate through PIM domain 
boundaries. In addition, there is currently no mechanism to
propagate BiDir-PIM group ranges and group range to RPA mappings 
into other domains.

For embedded RP and Bi-Dir, I read through several drafts and RFCs
and a bunch of email comments, and see no real reason why
it wouldn't work, although there is no mechanism yet
to specify that a group range is for BiDir (that could be easily
done, say, by setting the R,P,T bits in the flags field
to 1,0,1).

So, I would just say that

In IPv6 there is as yet no standards based mechanism for alerting routers that
an embedded RP group range is to be used for BiDir.

Regards
Marshall