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

Pekka, thanks for reading and specifically for confirming my
understanding of MBGP.

As promised, here is a list of specific changes that are planned to
appear in the next revision of the document in response to Alex's
commentes.  I'm about to submit a new version that incorporates all of
these changes.

If further changes are necessary, I will revise and resubmit, but I
plan to go ahead and submit a version with these changes before the
draft submission deadline.

Cheers,
-Hugh
----------------------------------------------------------------

I. All of Alex's Editorial changes.

I have not listed the specific editorial changes here; I did exactly what Alex
suggested.


II. Add text saying that hosts must implement IGMPv3/MLDv2, and
also the igmpv3/mldv2-changes-for-ssm document.

REPLACE in Section 4.2 (Requirements on the Host IP Module)

  A separate document describes how IGMPv3 and MLDv2
  are adapted to support source-specific multicast.

WITH

  A host that supports the SSM service model MUST implement the host
  portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6.  It MUST also
  conform to the IGMPv3/MLDv2 behavior described in
  [GMP-SSM].


III.  Add text mandating PIM-SSM and IGMPv3/MLDv2 for routers
      to section 5.2 (Router Requirements/Protocols)

REPLACE

  Companion documents will specify the required 
  modifications to those protocols to support SSM.

WITH

  A router that supports the SSM service model MUST implement the
  PIM-SSM subset of the PIM-SM protocol from [PIM-SM] and MUST
  implement the router portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6.
  An SSM router MUST also conform to the IGMPv3/MLDv2 behavior
  described in [GMP-SSM].


IV. Mandate that PIM-SSM implementation be able to use the unicast
topology for RPF lookups, also in section 5.2

ADD the following paragraph, after insertion III above.

  With PIM-SSM, successful establishment of an (S,G) forwarding path
  from the source S to any receiver depends on hop-by-hop forwarding of
  the explicit join request from the receiver toward the source.  The
  protocol(s) and algorithms that are used to select the forwarding path
  for this explicit join must provide a loop-free path.  When using PIM-SSM,
  the PIM-SSM implementation MUST (at least) support the ability to use the
  unicast topology database for this purpose.


V. References Changes

ADD a new normative reference to the IGMPv3/MLDv2-for-SSM document.

  [GMP-SSM]   H. Holbrook and B. Cain, 
  "IGMPv3/MLDv2 for SSM", draft-holbrook-idmr-igmpv3-ssm-07 (Work in Progress), June 2004.
  .PP

REPLACE the previous reference to the old PIM RFC with a reference
to the new one:

  [PIM-SM] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas.
  "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
  Specification (Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in
  Progress), July 2004.
  
MOVE the IGMPv3, MLDv2, and PIM-SM references to the normative
reference section, as they are all REQUIRED with a capital R.

The full diffs of the nroff source follow

===================================================================
RCS file: RCS/draft-ietf-ssm-arch.nroff,v
retrieving revision 1.6
diff -uw -r1.6 draft-ietf-ssm-arch.nroff

--- draft-ietf-ssm-arch.nroff	2003/10/20 07:40:04	1.6
+++ draft-ietf-ssm-arch.nroff	2004/07/17 07:17:07
@@ -9,22 +9,22 @@
 .ds RF PUTFFHERE[Page %]
 .ds CF
 .ds LH INTERNET-DRAFT
-.ds RH 19 Oct 2003
+.ds RH 18 Jul 2004
 .ds CH Source-Specific Multicast
 .ad l
 .in 0
 .na
 INTERNET-DRAFT          Source-Specific Multicast            H. Holbrook
-Expires Apr 19, 2004                                       Cisco Systems
+Expires Jan 18, 2005                                       Cisco Systems
                                                                  B. Cain 
                                                         Storigen Systems
-                                                             19 Oct 2003
+                                                             18 Jul 2004
 .sp 2
 .nr PI 0n
 .ce
 Source-Specific Multicast for IP
 .ce
-<draft-ietf-ssm-arch-04.txt>
+<draft-ietf-ssm-arch-05.txt>
 .sp
 .in 0
 .ne 4
@@ -48,10 +48,6 @@
 .PP
 The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html.
-.SH
-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].
 .PP
 .bp
 .SH
@@ -65,7 +61,7 @@
 For IP version 6 (IPv6), 
 the address prefix FF3x::/32 is reserved for source-specific
 multicast use.
-It defines an extension to the Internet 
+This document defines an extension to the Internet 
 network service that applies to datagrams sent to SSM addresses
 and defines the host and router requirements to support this extension.
 .NH 1
@@ -176,6 +172,10 @@
 which a client sends a multicast query directly to a "service
 location group" to which servers listen is not directly supported
 by SSM.
+.SH
+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].
 .PP
 This document
 defines the semantics of source-specific multicast addresses
@@ -386,10 +386,12 @@
 sends an unsubscription request for that channel to interface I.
 .PP
 These requests will typically be Internet Group Management Protocol
-version 3 messages for IPv4, or Multicast Listener Discovery
-Version 2 messages for IPv6 [IGMPv3,MLDv2].
-A separate document describes how IGMPv3 and MLDv2
-are adapted to support source-specific multicast.
+version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery
+Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2].
+A host that supports the SSM service model MUST implement the host
+portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6.  It MUST also
+conform to the IGMPv3/MLDv2 behavior described in
+[GMP-SSM].
 .NH 2
 Allocation of Source-Specific Multicast Addresses
 .PP
@@ -480,9 +482,19 @@
 communicate source-specific joins to neighboring routers (in
 particular, PIM-SM [PIM-SM]), and these protocols can, with slight
 modifications, be used to provide source-specific semantics.  
-Companion documents 
-will specify the required modifications to those protocols 
-to support SSM.
+A router that supports the SSM service model MUST implement the
+PIM-SSM subset of the PIM-SM protocol from [PIM-SM] and MUST
+implement the router portion of [IGMPv3] for IPv4 and [MLDv2] for IPv6.
+An SSM router MUST also conform to the IGMPv3/MLDv2 behavior
+described in [GMP-SSM].
+.PP
+With PIM-SSM, successful establishment of an (S,G) forwarding path
+from the source S to any receiver depends on hop-by-hop forwarding of
+the explicit join request from the receiver toward the source.  The
+protocol(s) and algorithms that are used to select the forwarding path
+for this explicit join must provide a loop-free path.  When using PIM-SSM,
+the PIM-SSM implementation MUST (at least) support the ability to use the
+unicast topology database for this purpose.
 .PP
 A network can concurrently support SSM in the SSM address range and 
 any-source multicast
@@ -743,6 +755,9 @@
 [ETHERv6]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
 Networks", RFC2464, Dec 1998.
 .PP
+[GMP-SSM]   H. Holbrook and B. Cain, 
+"IGMPv3/MLDv2 for SSM", draft-holbrook-idmr-igmpv3-ssm-07 (Work in Progress), June 2004.
+.PP
 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet
 Protocol.", RFC 2401.
 .PP
@@ -781,14 +796,15 @@
 October 2002.
 .PP
 [MLDv2] R. Vida, and L. Costa.
-"Multicast Listener Discovery Version 2 (MLDv2) for IPv6."  
-Work in Progress.
+"Multicast Listener Discovery Version 2 (MLDv2) for IPv6,"   RFC3810,
+June 2004.
 .PP
 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B.  "Socket Interface Extensions for Multicast Source Filters."  Work in Progress.
 .PP
-[PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 
-Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent
-Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, June 1998.
+[PIM-SM] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas.
+"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
+Specification (Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in
+Progress), July 2004.
 .PP
 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., 
 Jacobson, V., Helmy, A., Meyer, D., and L. Wei, 
@@ -832,6 +848,11 @@
 .SH
 Intellectual Property Rights Notice
 .PP
+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.
+.PP
 The IETF takes no position regarding the validity or scope of
 any intellectual property or other rights that might be claimed
 to  pertain to the implementation or use of the technology
@@ -855,7 +876,7 @@
 .SH
 Full Copyright Statement
 .PP
-Copyright (C) The Internet Society (2002).  All Rights Reserved.
+Copyright (C) The Internet Society (2004).  All Rights Reserved.
 .PP
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
@@ -885,5 +906,5 @@
 .\" .bp
 .\" .ls 1
 .\" Comment out the table of contents for now .PX
-This document expires Apr 19, 2004.
+This document expires Jan 18, 2005.
 
> 
> 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

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

