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

Brandon Williams <brandon.williams@akamai.com> Mon, 21 March 2016 18:08 UTC

Return-Path: <brandon.williams@akamai.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296BC12DA04 for <tram@ietfa.amsl.com>; Mon, 21 Mar 2016 11:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level:
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-I8ibf_Q6CA for <tram@ietfa.amsl.com>; Mon, 21 Mar 2016 11:08:14 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8849F12D9E7 for <tram@ietf.org>; Mon, 21 Mar 2016 11:08:12 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D9C3F3F4010 for <tram@ietf.org>; Mon, 21 Mar 2016 18:08:11 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id BA01D4F0CA for <tram@ietf.org>; Mon, 21 Mar 2016 18:08:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458583691; bh=jRxlmESDCfSKbdrLDVMxztjzTciusUqQrGXCaB0ChM4=; l=3972; h=To:References:From:Date:In-Reply-To:From; b=sbi6c50LKdIANnhGLtrgEEdGCADbJCfeKTpUSgc4f+9UZtOSBY+bqxcAF8vZdZ/EB FBYcSSpb929EwKuPKQHmlTDqKugQiXacd8P3YqgCavt587mrezbKPw8FuPw4h7mNTR wZESUovA+ux25rcIwA9udsc02eAxaL8eXoIIzKMk=
Received: from [172.28.112.97] (bowill.kendall.corp.akamai.com [172.28.112.97]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id B63921FC88 for <tram@ietf.org>; Mon, 21 Mar 2016 18:08:11 +0000 (GMT)
To: tram@ietf.org
References: <20160311043903.2754.65997.idtracker@ietfa.amsl.com> <ba3962af36e74174bb9c59c403c7485e@XCH-RCD-017.cisco.com>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <56F0388B.20805@akamai.com>
Date: Mon, 21 Mar 2016 14:08:11 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <ba3962af36e74174bb9c59c403c7485e@XCH-RCD-017.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/rL6nP1JUeYSJTKqURZiVYOnbu6I>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2016 18:08:17 -0000

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. 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.

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).

--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.