Re: [ssm] AD-review comments on draft-ietf-ssm-arch-04.txt

Hugh Holbrook <holbrook@cisco.com> Fri, 16 July 2004 00:12 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21104 for <ssm-archive@lists.ietf.org>; Thu, 15 Jul 2004 20:12:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlGIs-0002og-1r; Thu, 15 Jul 2004 20:10:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlGEI-0001G2-HD for ssm@megatron.ietf.org; Thu, 15 Jul 2004 20:05:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20625 for <ssm@ietf.org>; Thu, 15 Jul 2004 20:05:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlGEG-0006qn-Ou for ssm@ietf.org; Thu, 15 Jul 2004 20:05:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlGDP-0006Vm-00 for ssm@ietf.org; Thu, 15 Jul 2004 20:04:40 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BlGCf-00065B-00 for ssm@ietf.org; Thu, 15 Jul 2004 20:03:53 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2004 17:05:26 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6G03BId019343; Thu, 15 Jul 2004 17:03:22 -0700 (PDT)
Received: from holbrook-laptop.cisco.com (scorpion.cisco.com [171.69.18.74]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AUN85922; Thu, 15 Jul 2004 17:00:45 -0700 (PDT)
Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 014A310B7D8; Thu, 15 Jul 2004 17:05:57 -0700 (PDT)
From: Hugh Holbrook <holbrook@cisco.com>
To: Alex Zinin <zinin@psg.com>
In-reply-to: <1998261226.20040413143116@psg.com>
Subject: Re: [ssm] AD-review comments on draft-ietf-ssm-arch-04.txt
Message-Id: <20040716000557.014A310B7D8@holbrook-laptop.cisco.com>
Date: Thu, 15 Jul 2004 17:05:57 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Cc: holbrook@cisco.com, ssm@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: holbrook@cisco.com
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Sender: ssm-bounces@ietf.org
Errors-To: ssm-bounces@ietf.org

Hi, Alex.  

Thanks for your comments.  Sorry for the very delayed response; I was
out on paternity leave and got embarassingly far behind...  Anyway,
let me respond now.

- I will incorporate all of your editorial comments into the next
revision of the draft; thanks.

Regarding your other comments suggesting that this document needs to
address protocol requirements.  Generally, I think this is a good
idea.

The history on this is that when the draft was first written,
"PIM-SSM" as a concept did not exist -- the first revisions of this
predated the new pim-sm spec by quite a bit.  Likewise, IGMPv3 was
still at the very early draft stage, and I don't think MLDv2 had any
document at the time.  But things have obviously changed since the -00
version of the -arch documetn, and so I think your suggestion of
mandating some protocols to ensure interoperability is a good one.  So
here is a list of changes that I propose we make to the draft:

There are two places where I think we should consider the
ineroperability issue:

  hosts-to-routers
  router-to-router

Each of these is discussed below.

- For the host-to-router case, I think your suggestion of mandating
IGMPv3/MLDv2 for hosts and routers that wish to support the SSM
service is a good one.  This is essentially true in practice anyway,
so I don't anticipate this as being a contentious point.

One point that I'd like to solicit input from the list about is what
to say about draft-holbrook-idmr-igmpv3-ssm-07.txt.  This is the
document that describes IGMPv3/MLDv2 modifications and clarifications
to make SSM work better.  There are a lot of SHOULDs in the document,
but it really only has one MUST in it: it disallows the optional
IGMPv3 behavior in which an older-version report for (*,G) can
suppress an IGMPv3 report for (S,G).  This is a DoS prevention issue.
Otherwise, an attacker could use an IGMPv1 report to deny SSM service
to someone else on the same LAN.  My current thinking is to say that
draft-holbrook-idmr-igmpv3-ssm-07 MUST be implemented, but I don't
feel that strongly as this is at worst a DoS issue and is somewhat of
a corner case.  I'd appreciate comments from anyone on this topic.

- For the router-to-router case, In order to ensure interoperabiliity,
I think the document should say that routers that provide SSM service
MUST (at least) support the PIM-SSM subset of PIM from pim-sm-v2-new.
This is a practical requirement anyway, so it just codifies what is
the common practice, and is hopefully not controversial.

The final question in my mind is what if anything to say about the
protocol requirements to address SSM's need for an underlying topology
database that is used to route join messages toward the source.  This
really derives from the use of PIM-SSM for routing, because it does
not have its own topology exchange protocol.

I think it would be appropriate to say that the PIM-SSM implementation
MUST support the ability to use the unicast topology database for RPF
decisions, without mandating a specific protocol (e.g., DO NOT mention
OSPF, BGP, MBGP, etc.).  This requirement, if implemented in all
routers, will ensures that an SSM route can be (assuming sufficient
processing and memory in routers along the way) established from any
host that is reachable by unicast.  And I think this is exactly the
right requirement for this document.  This ensures interoperability
for both the inter- and intra-domain SSM routing cases without
specifically mentioning the distinction and without needing to require
any specific unicast routing protocol, which is I think the right
level of requirement.

I don't believe that there is really enough experience with the use of
a multicast-specific topology (with some minor exceptions like static
routes to multicast sources) to mandate anything about it.
Specifically, I don't think it's appropriate to mandate MBGP at this
point.  It is not a requirement for multicast interoperability, and I
don't think it would be appropriate to say anything about it in the
architecture spec.  This information is based on discussions with some
of the more knowledgeable folks on the topic at Cisco; anyone who has
different (or even the same) opinion on this topic is encouraged to
comment.

If there is rough consensus on the mailing list, then I will send some
proposed text to the mailing list and revise and resubmit the draft
this week.

Comments from the working group (or ADs) are appreciated.

Thanks again for the careful review, Alex.

-Hugh

> Folks-
> 
>  Please find attached my AD-review comments on the SSM architecture
>  document.
> 
> -- 
> Alex
> http://www.psg.com/~zinin/
> 
> Generally the document is in a great shape. Very good job. I have one meta
> issue and one editorial nit.
> 
> Meta:
> 
>  The document does not spell out what protocols hosts and routers MUST
>  implement. I.e., this kind of document is expected to specify the
>  mandatory-to-implement mechanisms that will ensure that hosts and routers can
>  interoperate. However, there is no place in the document where it says
>  something like "hosts supporting the SSM network service MUST implement IGMPv3
>  for IPv4 and MLDv2 for IPv6", or "routers supporting the SSM network service
>  MUST implement PIM-SSM..."
> 
> Editorial
> 
>  The following part:
> 
> > 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 [RFC 2119].
> 
>  should be moved inside the body of the document (preferably not in Abstract)
> 
>  Abstract:
> 
> > IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
> > designated as source-specific multicast (SSM) destination addresses and
> > are reserved for use by source-specific applications and protocols.  For
> > IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
> > source-specific multicast use.  It defines an extension to the Internet
>                                   ^^
>                                 needs to be expanded. "This document" ?
> 
> 
>  Section "Intellectual Property Rights Notice". To reflect the situation
>  with Apple, this section also needs to include the following paragraph
>  from RFC 2026.
> 
>          "The IETF has been notified of intellectual property rights
>          claimed in regard to some or all of the specification contained
>          in this document.  For more information consult the online list
>          of claimed rights."
> 
> 
> 
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm