Subject: Re: mboned: I-D ACTION:draft-ietf-mboned-ipv4-mcast-unusable-01.txt]

From: Bill Nickless <[email-masked]>
Date: Wed, 07 Jan 2004 15:17:15 -0600

Good afternoon Pekka,

I thought about your comments over the holiday break, and here's what I 
came up with:

Operationally, I think there are at least three places where access control 
lists should (by best practice) be installed: in the hosts/customer 
routers, at the edge of the AS (for PIM), and between ASes (for 
MSDP).  Using the "belt and suspenders" paranoid approach, I would suggest 
that the elements in each of these three access controls would be cumulative.

In other words:

The lines in Section 6 that refer to Section 7 should be installed on hosts 
(probably Ethernet kernel drivers) and on host-facing routers.

The lines in Section 6 that refer to Sections 7 and 8 should be installed 
on PIM routers that face other administrative domains.

The lines in Section 6 that refer to Sections 7, 8, and 9 should be 
installed on MSDP-speaking routers that peer with other administrative domains.

At first glance, I don't think this document is the place to include the 
above explanation; instead, I think that's better put in a BCP.

I was working on this document first because it was holding up some other 
RFCs, but expect to go through the IPv4 BCP shortly as well to include 
things like the above.

Does this make sense?  Should I go ahead and make the semi-editorial 
changes and re-issue, or... ?

At 03:23 PM 12/22/2003 +0200, Pekka Savola wrote:

>Comments below -- mainly, I have one big concern wrt. the structure of
>the document, which has an impact if we want this to be operationally
>useful, rather than just a reference of weird v4 multicast addresses.
>I personally think the former is closer to the target, but with
>clarifying text, the latter could also be OK..
>
>First question: this is for Informational, right?  It could also be
>BCP, but Info is fine by me and less paperwork besides :-).
>
>Second meta-question: would we want to look for unusable v6 multicast
>addresses as well?  Especially for the IGMP/MLD snoopers control plane
>clash perspective.  We'll have to tackle that at some point, but maybe
>it can wait a bit...
>
>Substantial
>-----------
>
>I'm questioning the structure of the document for the purpose of its
>usefulness.  Section 6 lists all the potentially bad (in some context)
>prefixes, and they are further describes in the next sections,
>including those that are completely unusable, those that should not be
>used interdomain, etc.
>
>It seems to me that while this serves a documentation purpose, the
>better way to structure these restrictions would be to write them
>like:
>
>6. Unusable Everywhere
>
>....
>
>7. Always Unusable in Interdomain
>
>....
>
>
>8. Miscellaneous
>
>(Note: actually I don't believe 232.0.0.0/8 and section 9 needs to be
>spelled out that much in this particular document.
>draft-ietf-mboned-ssm232-06.txt already pretty much includes about
>everything necessary....)
>
>-- that way, folks who want to take advantage of these, e.g., to
>create their multicast filters on routers based on the advice, don't
>have to go through a list of all addresses to find which they should
>block at their MSDP/interdomain borders, which should be used anywhere
>etc.
>
>Operationally one huge list is a maybe a good reference, but not
>really that useful beyond that.
>
>Thoughts about this approach?  (One doubt I have personally is
>whether it's possible to separate these addresses to these
>"useful categories" like "never useful" or "not useful in
>interdomain".
>
>
>Semi-editorial
>--------------
>
>13. References
>
>==> these need to be split to informative/normative.
>
>Editorial
>---------
>
>1. Status of this Memo
>2. Abstract
>3. Table of Contents
>
>==> these must be unnumbered sections
>
>4. Conventions used in this document
>
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are to be interpreted as described in RFC-2119 [RFC2119].
>
>5. Background
>
>==> this should probably be renamed to "Introduction", edited
>slightly, and the conventions, above, should be moved at the end of
>this section.
>
>14. Author's Address
>
>  ==> it'd probably also be a good idea to include the standard IPR
>notice, Copyright Notice and ISOC acknowledgement notices after this
>section.
>
>
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

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

---

From: David Meyer <[email-masked]>
Date: Fri, 9 Jan 2004 08:23:55 -0800

On Fri, Jan 09, 2004 at 04:39:07PM +0200, Pekka Savola wrote:
>> Hi,
>> 
>> On Wed, 7 Jan 2004, Bill Nickless wrote:
>> > MSDP).  
>> Agreed.
>> > Using the "belt and suspenders" paranoid approach, I would suggest 
>> To a degree..
>> This may not always be feasible, but otherwise I'd agree.
>>  
>> Yep.
>> I agree that if we want to *recommend* something, it should be better 
>> put in a BCP.
>> 
>> But what I'm mostly worried about here is the organization of the 
>> data.  I think it would probably be better, for everyone (and easier 
>> to refer to in the BCP as well) if it was organized by separating 
>> practically the three different categories of addresses to separate 
>> sections.
>> 
>> But if others disagree with this, that's fine  -- this is not a 
>> critical thing for the development of the document.
>> 
>> -- 
>> Pekka Savola                 "You each name yourselves king, yet the
>> Netcore Oy                    kingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

	Let's see if we can close on this. The WG LC timer runs
	out on this today. Pekka's were the only comments. Are
	there others (as he doesn't seem to feel that strongly
	about this; Pekka, correct me if I'm wrong).

	Dave

	[Note: Please use [email-masked] rather than
	[email-masked]. Thanks, Dave[
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Jan 2004 16:39:07 +0200 (EET)

Hi,

Agreed.

To a degree..

 

Yep.

---

From: Peter Koch <[email-masked]>
Date: Tue, 20 Jan 2004 19:58:38 +0100

> 	out on this today. Pekka's were the only comments. Are

sorry for being late, but here's another group that might not be usable
"locally". 239.7.7.0 is used by SGI's sdpd (Session Directory Server Daemon)
and thus not only unavailable for inter domain multicast (as of section 8),
but also on site.

-Peter

---

From: David Meyer <[email-masked]>
Date: Tue, 20 Jan 2004 11:43:39 -0800

>> and thus not only unavailable for inter domain multicast (as of section 8),

	Just curious. Do you know if this predates RFC 2365 (07.1998)?

	Thanks,

	Dave