Re: [ssm] what to say about scoping for v6 [was ...last call...]

Brian Haberman <bkhabs@nc.rr.com> Tue, 11 March 2003 14:23 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20314 for <ssm-archive@odin.ietf.org>; Tue, 11 Mar 2003 09:23:44 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BEbCa01462 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 09:37:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEbCO01451 for <ssm-web-archive@optimus.ietf.org>; Tue, 11 Mar 2003 09:37:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20301 for <ssm-web-archive@ietf.org>; Tue, 11 Mar 2003 09:23:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEZ9O01156; Tue, 11 Mar 2003 09:35:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEYbO01095 for <ssm@optimus.ietf.org>; Tue, 11 Mar 2003 09:34:37 -0500
Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20253 for <ssm@ietf.org>; Tue, 11 Mar 2003 09:20:37 -0500 (EST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BELNHE007428; Tue, 11 Mar 2003 09:21:33 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 09:09:30 -0500
Message-ID: <3E6DEDC1.7050301@nc.rr.com>
Date: Tue, 11 Mar 2003 09:08:01 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: holbrook@cisco.com
CC: Pekka Savola <pekkas@netcore.fi>, ssm@ietf.org
Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...]
References: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com>
In-Reply-To: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hugh Holbrook wrote:
> [ ... Snipping just the thread on scoping for ssm ]
> 
> My comments inline...
> 
> 
>>Date: Mon, 10 Mar 2003 08:01:49 -0500
>>From: Brian Haberman <bkhabs@nc.rr.com>
>>Cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org
>>
>>Pekka Savola wrote:
>>
>>>On Sun, 9 Mar 2003, Brian Haberman wrote:
>>>
>>>
>>>>>  The scope of the unicast-prefix based multicast address MUST NOT
>>>>>  exceed the scope of the unicast prefix embedded in the multicast
>>>>>  address.
>>>>>
>>>>>note: "embedded in the multicast address".  But as you should note here, 
>>>>>an address (particularly _SSM_, which is really not derived from the 
>>>>>unicast prefix) does not.
>>>>
>>>>The intent was that the scope of the SSM group address would
>>>>not exceed the scope of the SSM source address.  The scoped addr
>>>>arch forwarding rules *WILL* prevent a scoped address from leaking
>>>>out of the administrative zone.
>>>>
>>>>The overall issue though is not SSM-specific.  
>>>
>>>
>>>Yes and no: in ASM, the DR only checks that G is ok; not it must check 
>>>that both S and G are ok.
>>>
>>
>>Actually, the DR has to check both S and G to ensure that it does
>>not send a PIM Join across a scope zone boundary regardless of it
>>being ASM or SSM.  There was some text in the original PIM for v6
>>draft a long time ago.
>>
>>
>>>>That is, the
>>>>scoped addr arch is responsible for determining the forwarding
>>>>issues around scoped addresses.  I don't see a need for putting
>>>>any type of scoped address issues in the SSM doc.
>>>
>>>...
>>>
>>>
>>>>As stated above, I don't see a reason to deal with scoped addresses
>>>>in the SSM arch doc.
>>>
>>>
>>>I understand this argument and I agree with it, mostly: at this point, we
>>>may end up doing some nasty things (in ipv6 w.g.) with scoped address
>>>architecture anyway, so trying to specify everything in detail in the 
>>>specs before we know we have to do it seems premature.
>>
>>Agreed. :)
>>
>>
>>>So, I can support putting considerations like these in the scoped address 
>>>architecture document, but IMO, there *must* be a brief mention of the 
>>>issues and a pointer in e.g. Security Considerations section.
>>>
> 
> 
> A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt?
> 

That would be the beast.  RFC 3484 references it when discussing
the issue of scope within the source address selection policy.  It
can be an informative reference here.

> 
>>I don't see a problem with doing that.  The security section can mention
>>the issue and say that it is out of scope for this doc and is being
>>addressed elsewhere.
> 
> 
> So I'm trying to convert this discussion about scoping to concrete
> text.  Here's what the doc currently says about v6 scoped addresses.
> 
>   For IPv6, administratively scoped SSM addresses are created by choosing
>   an appropriate scope identifier for the SSM destination address.  Normal
>   IPv6 multicast scope boundaries are applied to traffic sent to an SSM
>   destination address.
> 
> I note that this paragraph is confusing because it says you can make a
> "scoped SSM addresses" when what it should say is "scoped SSM channel
> addresses".  Here is proposed text to incorporate what I think Pekka
> is suggesting.
> 
>   For IPv6, administratively scoped SSM channel addresses are created
>   by choosing an appropriate scope identifier for the SSM destination
>   address.  Normal IPv6 multicast scope boundaries are applied to
>   traffic sent to an SSM destination address, including any relevant
>   boundaries applied to both the source and destination address.
> 
> Question 1: Do you accept the above text?  I'm not sure I captured the
> issue, so I'd appreciate a better alternative if you see one.

I am ok with it, but I didn't raise the issue either.  So, I would
like Pekka's assessment before we declare victory. :)

> 
> Question 2: If not, is there an appropriate reference for "Normal IPv6
> multicast scope boundaries," or is it preferable to intentionally
> leave the document without a reference?

I don't see a problem with having an informative reference for the
scoped addr arch doc.

> 
> Question 3: Should we add text to clarify the "embedded address" text
> in RFC3306.  I can think of three options:
> 
> Either prohibit it:
> 
>   For IPv6, senders MUST ensure that the scope of a channel
>   destination address does not exceed the scope of the channel source
>   address.
> 
> Or allow it:
> 
>   For IPv6, the scope of a channel destination address MAY exceed the
>   scope of the channel source address.  Normal forwarding rules for
>   scoped traffic apply to a packet sent to such a channel.  Normal
>   multicast scoping rules apply for any routing protocol messages
>   (e.g., "joins") referring to such a channel.
> 
> Or say nothing:
> 
> I am inclined to do the latter, and I think this is what both of you
> are saying.  Am I right?
>

I agree, the latter works for me.  Should we add a reference to RFC
3484 as a note on how the address selection could occur?

Brian

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