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

[<[e-mail]>]

Hi Behcet,

There is a real value to ensure compatibility with unicast based and embedded-RP for ASM. As pointed by T. Chown this would require to update rfc3306 but I don't think this is problematic.

Now for Stig's Idea to reserve an additional /96 prefix (for ASM, T=0), we need more feedback from the WG.

Cheers,
Med
 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] 
>De la part de Behcet Sarikaya
>Envoyé : vendredi 17 août 2012 21:21
>À : Stig Venaas
>Cc : [e-mail]
>Objet : Re: [MBONED] 
>draft-ietf-mboned-64-multicast-address-format-03.txt
>
>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.
>
>Behcet
>_______________________________________________
>MBONED mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mboned
>