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

[Stig Venaas <[e-mail]>]

On 8/17/2012 12:20 PM, Behcet Sarikaya wrote:
> On Fri, Aug 17, 2012 at 1:06 PM, Stig Venaas <[e-mail]> wrote:
>> Hi Tim
>>
>>
>> On 8/16/2012 4:12 PM, Tim Chown wrote:
>>>
>>> On 15 Aug 2012, at 02:43, Stig Venaas <[e-mail]> 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...
>
>
> We just wanted to define two reserved multicast IPv6 prefixes and
> after giving up modifying IP addressing architecture, we are now
> talking about changing so many RFCs.
>
> In this mail earlier Stig said:
>
> http://www.ietf.org/mail-archive/web/mboned/current/msg01663.html
>
> we can state that inter-domain operation is not a requirement and we
> do not support embedded-RP.

I wrote something slightly different:

"Of course we could argue whether we need to support embedded-RP.
It is very useful, especially inter-domain, but if that is not a
requirement, we may not need to support it."

I left it open to discussion. I'm trying to get all the options on the
table here.

Alternative 2 above is sufficient if we don't care about embedded-RP,
and is in draft-kumar-mboned-64mcast-wkp-address-00.txt.

But I do see value in both unicast-prefix based addressing (a good
way to ensure your addresses are unique), and embedded-RP (which is
necessary inter-domain, but may at times be used intra-domain). And I
do know deployments using inter-domain embedded-RP.

If we want to support unicast-prefix based addressing or
embedded-RP, it appears we need to update RFC 3306.

Note that we would not change 3306 in any way. We only need
this draft to say that it Updates 3306.

Stig

>
> Behcet
>