Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt

You're correct that the MTU text in stunbis hasn't yet been changed to 
reflect what I believe was the previous consensus. I've raised this on 
the list but haven't seen any responses yet. Marc didn't want to make 
this change without getting confirmation that the WG had actually 
agreed. I'll try to touch base with a couple of people this week to see 
if we can get that closed.

--Brandon

On 03/22/2016 03:53 AM, Tirumaleswar Reddy (tireddy) wrote:
> Hi Brandon,
>
> Please see inline
>
>> -----Original Message-----
>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams
>> Sent: Monday, March 21, 2016 11:38 PM
>> To: tram@ietf.org
>> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt
>>
>> Hi Tiru,
>>
>> Thanks for the update. I've got two minor comments.
>>
>> The new text about fragmentation and ticket length is less specific than the
>> old text, but it still repeats guidance from the RFC that I believe we've agreed
>> to change in STUNbis.
>
> I don't see any specific changes in STUNbis yet to handle fragmentation !
>
>> How about instead of this: "...
>> assume that the path MTU is unknown and MUST ensure that the ticket
>> length is restricted to avoid UDP fragmentation ...", we say this: "...
>> assume that the path MTU is unknown and use a ticket length in accordance
>> with published guidance on STUN UDP fragmentation ...". This wording
>> defers all requirements language to the STUN RFC but still calls out the
>> possible concern.
>
> Okay, updated.
>
>>
>> In the paragraph describing the handling of a verified Refresh request, it
>> states "The server then updates it's state data with the new client IP address
>> and port but does not discard the old 5-tuple from it's state data." However,
>> in the next paragraph, the new text states "After receiving any of those
>> messages, a TURN server updates its 5-tuple with the new client IP address
>> and port." I think what you want in the second paragraph is "After receiving
>> any of those messages, a TURN server discards the 5-tuple associated with
>> the old MOBILITY-TICKET from its state data." In that paragraph, you can
>> probably also say that it discards the old MOBILITY-TICKET at that point
>> without waiting for the timeout, although the text about holding onto the old
>> MOBILITY-TICKET hasn't appeared yet (it's in the next paragraph).
>
> NEW:
> After receiving any of those messages, a TURN server discards the 5-tuple associated with the old MOBILITY-TICKET and the old MOBILITY-TICKET from its state data.
>
> -Tiru
>
>>
>> --Brandon
>>
>> On 03/10/2016 11:48 PM, Tirumaleswar Reddy (tireddy) wrote:
>>> This revision adds support for make-before-break and addresses
>> comments from Brandon.
>>>
>>> -Tiru
>>>
>>>> -----Original Message-----
>>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
>>>> drafts@ietf.org
>>>> Sent: Friday, March 11, 2016 10:09 AM
>>>> To: i-d-announce@ietf.org
>>>> Cc: tram@ietf.org
>>>> Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>>> This draft is a work item of the TURN Revised and Modernized of the IETF.
>>>>
>>>>           Title           : Mobility with TURN
>>>>           Authors         : Dan Wing
>>>>                             Prashanth Patil
>>>>                             Tirumaleswar Reddy
>>>>                             Paal-Erik Martinsen
>>>> 	Filename        : draft-ietf-tram-turn-mobility-01.txt
>>>> 	Pages           : 12
>>>> 	Date            : 2016-03-10
>>>>
>>>> Abstract:
>>>>      It is desirable to minimize traffic disruption caused by changing IP
>>>>      address during a mobility event.  One mechanism to minimize
>>>>      disruption is to expose a shorter network path to the mobility event
>>>>      so only the local network elements are aware of the changed IP
>>>>      address but the remote peer is unaware of the changed IP address.
>>>>
>>>>      This draft provides such an IP address mobility solution using
>>>>      Traversal Using Relays around NAT (TURN).  This is achieved by
>>>>      allowing a client to retain an allocation on the TURN server when the
>>>>      IP address of the client changes.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-01
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-01
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> tram mailing list
>>>> tram@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tram
>>>
>>> _______________________________________________
>>> tram mailing list
>>> tram@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tram
>>>
>>
>> --
>> Brandon Williams; Chief Architect
>> Cloud Networking; Akamai Technologies Inc.
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

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