Re: [tram] Review of dual allocation in TURNbis-11

[Brandon Williams <[e-mail]>]

Hi Marc,

Tiru had one response and one question below. Any thoughts?

--Brandon

On 03/04/2018 08:30 AM, Konda, Tirumaleswar Reddy wrote:
> Hi Marc,
> 
> Please see inline
> 
>> -----Original Message-----
>> From: Marc Petit-Huguenin [mailto:[e-mail]]
>> Sent: Saturday, March 3, 2018 2:47 AM
>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> Subject: Re: [tram] Review of dual allocation in TURNbis-11
>>
>> As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed
>> on below, and found some discrepancies.  See inline.
>>
>> On 02/09/2018 04:51 AM, Konda, Tirumaleswar Reddy wrote:
>>>> -----Original Message-----
>>>> From: Marc Petit-Huguenin [mailto:[e-mail]]
>>>> Sent: Sunday, October 22, 2017 9:38 PM
>>>> To: Konda, Tirumaleswar Reddy
>>>> <[e-mail]>; [e-mail]
>>>> Subject: Re: [tram] Review of dual allocation in TURNbis-11
>>>>
>>>> Inline.
>>>>
>>>> On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote:
>>>>> Thanks Marc for the detailed review, Please see inline
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit-
>>>>>> Huguenin
>>>>>> Sent: Saturday, October 14, 2017 12:59 AM
>>>>>> To: [e-mail]
>>>>>> Subject: [tram] Review of dual allocation in TURNbis-11
>>>>>>
>>
>> [snip]
>>
>>>>>
>>>>>>
>>>>>> - Section 6.2
>>>>>>
>>>>>> I would suggest to make ADDRESS-ERROR-CODE more generic by
>>>> renaming
>>>>>> it as WARNING-CODE and use the same format than for ERROR-CODE.
>>>> Then
>>>>>> allocate a new error code for that specific warning.  I would
>>>>>> suggest to request the 0x8009 codepoint for that attribute.
>>>>>
>>>>> I don't understand the need to change ADDRESS-ERROR-CODE !
>>>>
>>>> To make it more generic and reusable in future specifications.
>>>
>>> ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE,
>> ADDRESS-ERROR-CODE signals the IP address family for which the warning is
>> generated + all the fields in the ERROR-CODE.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Also I think we needs two different warnings, one that states that
>>>>>> dual allocation is not available in a TURNbis server, but both
>>>>>> protocols are available, and another that says that dual allocation
>>>>>> failed because one of the two protocols is not available.  This is
>>>>>> to let the client know that it is useless to try another allocation
>>>>>> for the
>>>> missing protocol.
>>>>>
>>>>> I don't get the reason for two different warnings.
>>>>
>>>> A server may support both IPv6 and IPv4 allocations and not support
>>>> dual allocation, in which case the client can do a second allocation
>>>> for the IPv6 relayed address.
>>>
>>> If the server does not support dual allocation but supports both IPv6 and
>> IPv4 allocations, it will only allocate the IPv4 relayed address and not will not
>> return ADDRESS-ERROR-CODE in the response, the client will know the
>> server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute
>> (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute).
>>>
>>>>
>>>> Alternatively the server may not support IPv6 at all, in which case
>>>> the second allocation will fail and was unnecessary.
>>>
>>> ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02
>> (IPv6 address family)) and the reason for failure (440 (unsupported address
>> family)).
>>>
>>> Cheers,
>>> -Tiru
>>>
>>>>
>>>> Using two different warnings permits to know if the second allocation
>>>> will succeed or not.
>>>>
>>>>>
>>>>>>
>>>>>> What is the policy when reserving the next port with the EVEN-PORT
>>>>>> attribute in a dual allocation, but one of them fails to find a
>>>>>> pair of subsequent ports available?
>>>>>
>>>>> It's discussed in section 6.1
>>>>>
>>>>> <snip>
>>>>>     Clients MUST NOT
>>>>>     include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
>>>>>     that contains an EVEN-PORT attribute with the R bit set to 1.
>>>>> </snip>
>>>>>
>>>>>>
>>>>>> It is not said that the Allocate successful response must contain
>>>>>> two XRAs after a successful dual allocation.
>>>>>
>>>>> Good point, Updated draft.
>>
>> I cannot find this update in turn-14.
> 
> This comment is partially addressed in -12 revision, step 9 (in Section 6.2 in -12 revision and Section 7.2 in -14 revision) is updated to discuss dual allocation.
> <snip>
> If the server can fully meet
> the request, then the server allocates one IPv4 and one IPv6
> relay address, and returns an Allocate success response
> containing the relayed transport addresses assigned to the dual
> allocation.
> </snip>
> 
> NEW:
> If the server can fully meet
> the request, then the server allocates one IPv4 and one IPv6
> relay address, and returns an Allocate success response
> containing the relayed transport addresses assigned to the dual
> allocation in two XOR-RELAYED-ADDRESS attributes.
> 
>>
>>>>>
>>>>>>
>>>>>> I would also suggest to add some text that says that when a TURNbis
>>>>>> server sends an Allocate success response, it must always send the
>>>>>> XRAs in the same order than the RAFs were sent.  So in case the
>>>>>> server sends back by mistake two XRAs, the first one matches the
>>>>>> one
>>>> requested by the client.
>>
>> Did not get answer to that and did not see it in turn-14.
> 
> I did not get this comment. If a request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, the request is rejected by the server. Further, only IPv6 address family is allowed in the
> ADDITIONAL-ADDRESS-FAMILY attribute.
> 
> 
>>
>>>>>>
>>>>>> The bullet list at the end needs also to be fixed for dual allocation.
>>>>>
>>>>> Agreed, fixed.
>>>>>
>>>>>>
>>>>>> - Section 6.3
>>>>>>
>>>>>> Here's too, the text needs to be updated for the dual allocation case.
>>>>>
>>>>>
>>>>> Yup, updated.
>>>>>
>>
>> Same, there is no update since -11 in section 7.3 (formerly 6.3)
> 
> This comment is addressed in -12 revision itself, the updated text uses "relayed transport address or addresses" and " address family or families" to discuss the
> dual allocation case.
> 
> Cheers,
> -Tiru
> 
>>
>> --
>> Marc Petit-Huguenin
>> Email: [e-mail]
>> Blog: https://marc.petit-huguenin.org
>> Profile: https://www.linkedin.com/in/petithug
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
> 

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.