Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24

[Brian Haberman <[e-mail]>]

Pekka Savola wrote:
> On Sat, 8 Mar 2003, Brian Haberman wrote:
> 
>>>Perhaps Brian Haberman, as a co-author of scoped address architecture, can 
>>>comment on this.
>>>
>>>You're right that this is not really SSM-specific except in one fashion:  
>>>sources indicate interest in (S,G) channels, not just G.  So, what if on a
>>>web page someone publishes a channel with (fe80::1, ff3e::1) -- or the
>>>same for site-local addresses?  This is one area which does seem 
>>>SSM-specific. 
>>
>>Actually it is not SSM specific.  Someone could publish an FTP link
>>on a webpage that specifies FE80::5 as the target.  If you reach the
>>webpage using a global address, there is nothing that can be done
>>about it.
> 
> 
> This is slightly different: the addrarch document is relatively clear on 
> how the routers should handle such an address.
> 
> Is the SSM document clear on how (fe80::1, ff3e::1) is handled?  I'm not 
> sure.
> 

See below.

> 
>>Also consider that the rules in RFC 3306 state that the scope of
>>the multicast address cannot exceed the scope of the unicast prefix
>>from which it derives.  Even though it is not specifically stated
>>for SSM, it applies.  So, an SSM channel cannot have a group address
>>that exceeds the scope of the unicast address.
> 
> 
> More specifically it states:
> 
>    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.  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.

> 
> So, I think this is *not* clear.
> 
> 
>>>The problem as above seems to be that the source address for a channel 
>>>needs to be published in some fashion.  Publication of non-unique (S,G) 
>>>may be a problem.  Of course, one could argue that this is not so much 
>>>different from publisting an admin-scoped ASM G..
>>>
>>>I'm not sure what to think of this issue -- so other comments would be 
>>>useful.
>>> 

As stated above, I don't see a reason to deal with scoped addresses
in the SSM arch doc.

>>
>>As stated above RFC 3306 does have restrictions on what the scope
>>of the group address can be.
> 
> 
> As above, I'm not sure how this applies to RFC3306 addresses which do not 
> depend on the prefix, ie. SSM.
> 

I consider the source address of an SSM group to be equivalent to
the unicast prefix used in an RFC 3306 generated address.

> 
>>>It seems to me that this would imply that no such reserved range exists 
>>>for SSM?
>>>
>>>This seems like an issue that we must be very careful of, so that no one 
>>>could say this document is trying to usurp either Proposed Standard.
>>>
>>>Brian as an author for both can probably clarify at least on the intent.
>>
>>Not sure I quite understand the issue.  The SSM range is to be
>>allocated out of FF3x::/96, however 3306 reserves the entire /32
>>for use later on with bigger group ID values.
> 
> 
> Yes.
>  
> 
>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with
>>permanently allocated IPv6 multicast addresses.  This is for
>>consistency with permanent IPv4 multicast addresses.  That
>>means that T=0 in the flags field.  I would expect that SSM
>>applications would allocate group IDs out of the 0x80000000 to
>>0xFFFFFFFF range for SSM channels.
> 
> 
> But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue 
> that the reservation does not hold.

Not sure what you mean here.  3307 is very explicit in what IANA
is reserving for group IDs.

> 
> IMO, reserving 0x8... to 0xf for apps would be a bad decision.  SSM is
> _source_ specific.  It makes very much sense for apps/users to use as
> simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like 
> FF3X::8000:0001, FF3X::8000:0002, etc.

But there is a bigger issue.  One of the goals of 3307 is to help
prevent collisions at the layer-2 mapping of group addresses.  By
having separate 32-bit ranges for the group IDs, it is possible to
minimize the number of collisions that occur at the MAC layer.

> 
> There doesn't seem to be need for this kind of address reservation is
> necessary for SSM; if, for some particular reason, reservation is
> necessary, it would seem to be better done at the end of the address
> space.
> 

But, the end of the address range collides with existing assignments
already delegated in RFC 2375.  That is why 3307 uses the low end of
the range for permanent group IDs.

Brian

_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm