Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

Hi Tim

On 8/16/2012 4:12 PM, Tim Chown wrote:
> On 15 Aug 2012, at 02:43, Stig Venaas <stig@venaas.com> wrote:
>
>> On 14.08.2012 14:43, Lee, Yiu wrote:
>>> Hi Stig,
>>>
>>> Since we want T=1, this will not meet the "well-known" requirement defined
>>> in RFC4291. If we don't want to define a flag, what is the proper way to
>>> describe ffxx:8000::/20 and ffxx:0:8000::/96?
>>
>> You could list them for all values of xx perhaps. I would maybe use
>> "x" and "y" and then discuss the allowed values.
>>
>> There are scope relative allocations today, the main thing is that we
>> don't want to require the flags to be "0". Or maybe we want to require
>> the T-bit to be set. As I wrote earlier, I would think of these
>> addresses as transient, and T=1 is required for Embedded-RP etc.
>>
>> The issue though is that if T=1, then it is not really an IANA
>> allocation as I see it, because IANA allocations have T=0. But if there
>> is IETF consensus, then one can still reserve these prefixes.
>
> I agree with Stig; there are multiple prefixes being reserved here.
>
> The text is effectively updating both RFC3306 and RFC3956 since the above prefix is setting a bit in the reserved bit range of both those specifications.  RFC3306 also says all those reserved bits (17-24) must be zero, while RFC3956 doesn't explicitly say that for bits 17-20 (it probably should, if you're now using one of those bits).

You're right about 3306. I wonder now if instead of practically
reserving a specific value for the entire nibble of remaining
reserved bits in 3306, it would be better to reserve just one of
the bits. I don't think it updates 3956, because it doesn't talk
about those bits at all, AFAICT.

> Both RFCs say that if R or P flags are set, then T must be set too, so I'm not sure you have freedom to say "if T=1" if you want to support those two methods.

Yes, that's why I've been saying that we can't just get an IANA
allocation. We need T=1 for this to work, and IANA is allocating
ASM with T=0.

> Finally, it may make more sense to use ffxx:1000::/20 for ASM, and thus only use the rightmost bit of the four reserved bits (for RFC3956 at least)?

Yes, but it would mean that if in the future one wants to use a
new reserved bit for another purpose, then it won't work for
this purpose. I like the idea of using a single bit actually.

So here is an alternative proposal. Do you think it's better?

1. Update 3306 and give a new meaning to one of the remaining
    reserved bits.

2. Get a /96 for ASM from IANA (which would have T=0).

The first would allow for 3306 and 3956 addressing, which I
think is useful.

The second would allow for uses where people don't care for
that other type of addressing, and may also be useful if you
want to use more or less fixed addresses, that does not use
any particular unicast address.

The alternative of just getting a /96 for ASM from IANA is
in draft-kumar-mboned-64mcast-wkp-address-00.txt.

I guess just doing IANA assignments and reserving a bit
from 3306 are slightly separate problems, with different
issues and uses.

Finally, we also need a /96 for SSM. That can't just be
an IANA assignment either. One interesting thing here is
maybe that SSM is based on 3306 with plen and prefix set
to 0. So if a bit is reserved (from 3306), then I think
it would technically apply to SSM as well. But the SSM
implementations I've seen (as well as a couple of RFCs)
assume that these reserved bits are all 0. Not ignored
as they should have been...

Stig

> Tim
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>