Subject: RE: mboned: I-D on overview of multicast routing

From: James Lingard <[email-masked]>
Date: Mon, 29 Nov 2004 18:31:07 -0000

Pekka,

I've read your draft and think it's a really good summary of the current
state of play, which fills an obvious hole in the set of IETF documentation.

Regarding the questions you ask in the document and your email:

-  I think it's best to keep these two documents separate.  They're both
fairly self-contained, and are sufficiently long that two documents are not
over-the-top and make the text slightly more digestible.  It may be a good
idea to have them published together and reference each other, if this is
possible.
-  Section 2.1.3 is fine where it is, not in an appendix.
-  Section 2.5 is useful to include, and makes the document slightly more
comprehensive for little extra length.

Here are a few other high-level points.

-  The section "Setting Up Multicast Forwarding State" (currently section
2.3) is the most important in the document.  It should come before "Learning
Active Sources" (currently section 2.2), and possibly before "Distributing
Topology Information" (currently section 2.1).

-  The title of section 2.4 (currently "Configuring Network Elements")
should be changed to something like "Configuring and Distributing RP
Information", which is what it is really about.  The current title led me to
expect something about the standard MIBs.

-  I think a short section on BGMP would be very useful.

-  Section 2.4.3 claims that BSR is unnecessary for IPv6, because we have
Embedded-RP.  Is it really the case that no-one wants to do any ASM with
IPv6 other than using Embedded-RP?  The BSR authors are currently doing work
to give better support for IPv6 administrative scoping in BSR.  Is this
unnecessary?

I also have a whole bunch of editorial comments - I'll send them to you
directly.

Regards,
James.

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pekka Savola
Sent: 25 November 2004 09:59
To: [email-masked]
Subject: mboned: I-D on overview of multicast routing 

Hi,

There was some support at IETF61 for creating a similar document as 
the "multicast address architecture", but about multicast routing.

I've submitted a short I-D on this, but as it wasn't published 
yesteday yet, here it is:

http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-routingarch-00.txt

Abstract
    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.
[....]
    This memo deals with:

    o  distributing multicast topology information (Section 2.1),
    o  learning active sources (Section 2.2),
    o  setting up multicast forwarding state (Section 2.3),
    o  configuring the multicast network elements (Section 2.4),
    o  interacting with hosts (Section 2.5), and
    o  restricting the multicast flooding in the link layer (Section
       2.6).

Comments are welcome, of course.  In particular, I'd be interested in 
hearing if folks think this should be merged in the same document with 
the addressing architecture.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Nov 2004 21:07:08 +0200 (EET)

Hi,

I'm planning to rev the document reasonably soon -- if I have time -- 
because I'll be out on holiday next week, and there have been good 
comments.  So, keep them coming, especially if you want to see them in 
-01! :)

> state of play, which fills an obvious hole in the set of IETF documentation.

Thanks a lot for your quick comments.  Inline..

> idea to have them published together and reference each other, if this is

Agreed.  I certainly have a "more 15 pages pages is something that 
gets to the bottom of the pile, and close to 30 pages will rarely be 
read" impression :)

> comprehensive for little extra length.

Thanks.  I'll keep these as is.

> Topology Information" (currently section 2.1).

True enough, I guess it could be the first section.

> expect something about the standard MIBs.

True.  I used a generic title, but couldn't came up with anything 
except RP configuration mechanisms :).

> -  I think a short section on BGMP would be very useful.

Very good point, I had already forgotten to include that one.

> to give better support for IPv6 administrative scoping in BSR.  Is this

Well.. my perception is that you don't technically _need_ it, but it 
has been a nice thing to have around prior to embedded-RP came around 
and was implemented.

Personally, I think it's worthwhile to push through the BSR spec, 
maybe as Experimental, but not spend a lot of work on it.  IMHO the 
key point is not to get tangled expanding it, but publish what works 
and is implemented in the short order.

After all, many people have went to using an anycast address instead, 
and there aren't all that many cases for it w/ embedded RP.  It's 
useful to have an implementable spec out even though it might not be 
used all that much anymore.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Nov 2004 21:07:37 +0100

On Mon, Nov 29, 2004 at 09:07:08PM +0200, Pekka Savola wrote:
[...]
> On Mon, 29 Nov 2004, James Lingard wrote:
[...]
> has been a nice thing to have around prior to embedded-RP came around 

There are some intradomain application where you want to have hardcoded
IPv6 addresses for some applications. Typically for "service discovery".
One example is the DHCPv6 "All DHCP Servers" address FF05::1:3. If you
want to use embedded-RP, then your applications will need to somehow
learn the prefix or RP to use first.

I'm not sure how to do failover with IPv6 and embedded-RP either. Well,
I can think of some ways, but easier with BSR.

> and is implemented in the short order.

Well, it's needed for IPv4, embedded-RP is no help. BSR has been part
of the PIM spec for a long time and there are interoperable
implementations. Although I'm not convinced all do.

With a working spec for IPv4, it's trivial to have the same for IPv6.

> used all that much anymore.

Stig