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

hi,

On 8/18/2012 Saturday 2:06 AM, Stig Venaas wrote:
> 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.

Sounds good, and it works for SSM, ASM with unicast-based prefix feature
and ASM with embedded-rp feature.

>
> 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. 
Sorry, I'm a little confused here. If 1 bit approach works, why do we
need a /96 for SSM? Did I miss anything?

Cheers,
Jacni

> 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
>>
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
> .
>