Re: [dhcwg] Review Request for draft-ietf-softwire-multicast-prefix-option

[<[e-mail]>]

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De 
>la part de [e-mail]
>Envoyé : mercredi 4 avril 2012 18:21
>À : Ted Lemon
>Cc : [e-mail]; Xiaohong Deng; Jacni Qin
>Objet : Re: [dhcwg] Review Request for 
>draft-ietf-softwire-multicast-prefix-option
>
>Dear Ted,
>
>Yes, we can do.

To avoid confusion, I meant we could do it that way but we prefer to have one single option for the reason explained below.

>
>FYI, we defined these as separate sub-options in 
>http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix-
>option-01 but the authors finally agreed to define it as a 
>single option. We thought it was more simple. A more serious 
>issue is to associate the provisioned U_PREFIX64 with the 
>multicast service and avoid using it for unicast. An example 
>would be a provider deploying NAT64 with a dedicated PREFIX64 
>(RFC6052) distinct from the one used for IPv4/IPv6 multicast. 
>Having all these pieces of information in one single packet 
>ensures the provisioned information will be used only for 
>multicast services.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : Ted Lemon [mailto:[e-mail]] 
>>Envoyé : mercredi 4 avril 2012 18:05
>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>Cc : [e-mail]; Xiaohong Deng; Jacni Qin
>>Objet : Re: [dhcwg] Review Request for 
>>draft-ietf-softwire-multicast-prefix-option
>>
>>Why is this a single option?   It seems like you are conveying 
>>three separate pieces of information, not all of which will be 
>>populated, so it would be better to have three options, and 
>>then the client can request all three, and the server can 
>>return the ones that are configured?   Or am I 
>>misunderstanding what you are trying to do here?
>>
>>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg
>