IETF Logo Mail Archive

Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

Simon Perreault <sperreault@jive.com> Tue, 22 November 2016 18:55 UTC

Return-Path: <sperreault@jive.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 E839B129E78 for <tram@ietfa.amsl.com>; Tue, 22 Nov 2016 10:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.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 EeOdcorBdIy9 for <tram@ietfa.amsl.com>; Tue, 22 Nov 2016 10:55:52 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71480129E72 for <tram@ietf.org>; Tue, 22 Nov 2016 10:55:52 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id x23so10317562pgx.1 for <tram@ietf.org>; Tue, 22 Nov 2016 10:55:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Qhpu4Qe2scRpB78THeK8N7aUFH+OslnK+2kgVLtcCJs=; b=BfzdZLH2BwXgyBt051x6dToMOwqqC5VwhF1EoeCA0Xobw8f8gJxY1yw2YH3EWjxzdr K7zbVS+TTwscuEpI+AxsJG43GTb5yyowh6gxHKUbGGwMrifD5jS2GQsT6arnbcD/DlTY /RbYrS7AZK/CYqwVy64iNiWqd6OoGT7q+OXPpg3v84Bbc51SxFtgWXim/Fbq0kpglP1q HfcYkX+FZsT+BT8x2G0LLatasuNSUAFdLRk38Br+wDuRwMXYH9PXY57D6k2zcVcSoR3t UnO/dOOZzFpHOEkErX3RncSVO1fdoOUlb5sK1G9DkSPofuzS6MmJx1gVWlRMS7UX1K5g 1coQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Qhpu4Qe2scRpB78THeK8N7aUFH+OslnK+2kgVLtcCJs=; b=eYbnrE1H6E9+bPI5tq2UYiRmHGW40GCamzZdgiscUL2rAvLdMM64vfHqe/Bp2AIxJi 6FnhpyyGBa1GWhu4ZCY0B9X05wmgph9H61Bebvbi+LkbOkYw8mH4ock28ZpvJaYEjusw y5eqATTZBQ0EJaedjteeM/2Jz07N/EFhk2gRZrMWpB+WLFLY7iNiNqQ0bd1uljsNjj4g DIskyroxkKnDx1KO7yXczCdwkwbMerNp0yN1sNGuZiXmK4ZjxbikcziT71dsXgOgnDB/ ri0h925xhIsO7q7aqmufYAs9rPA0KPOfYLN9tf9jLLSeF0l/cDA1ViCIT3mVQJvyDWJQ gaPA==
X-Gm-Message-State: AKaTC015EVrh/VXKnaOI4cM8fXWZaCTxq86bvzmL8uCn6B+C73OwU8PeGzmsTk5GHLHE1wNe+Y7V4AtLaYrFZ7yLC0m+uyKcJL+2I2Kzapy8qqVym10EqQ4=
X-Received: by 10.98.147.135 with SMTP id r7mr26722752pfk.117.1479840951970; Tue, 22 Nov 2016 10:55:51 -0800 (PST)
Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:ed11:4547:a806:fc6d]) by smtp.gmail.com with ESMTPSA id l69sm46924721pfk.34.2016.11.22.10.55.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 10:55:51 -0800 (PST)
To: Karl Stahl <karl.stahl@ingate.com>, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, 'Brandon Williams' <brandon.williams@akamai.com>, "'Prashanth Patil (praspati)'" <praspati@cisco.com>, tram@ietf.org
References: <E1FFF433-D80C-4567-9C7D-16E46C025F00@cisco.com> <010501d23ba4$875bc760$96135620$@stahl@ingate.com> <295fd023-c73e-84f1-3acc-1b578c042434@akamai.com> <02cc01d23e4e$2da03150$88e093f0$@stahl@ingate.com> <a5f77a074936495e96d60d7cc83c6f37@XCH-RCD-017.cisco.com> <8db2f352-fa9b-8376-f6d6-fd53dd5abe05@akamai.com> <011701d24110$e76b8070$b6428150$@stahl@ingate.com> <d2442639-a81c-cd8d-dfd6-663a69f3f420@akamai.com> <982922d0d9c1411cb0a70f413b19220d@XCH-RCD-017.cisco.com> <583206ac.8558620a.5877d.48e5SMTPIN_ADDED_BROKEN@mx.google.com> <ef69c622-e1d9-7ec6-2ec2-e1ca00285803@jive.com> <583482f5.46d9540a.d3af4.d038SMTPIN_ADDED_BROKEN@mx.google.com>
From: Simon Perreault <sperreault@jive.com>
Message-ID: <82658049-45c6-0626-b6b5-b8684e92ab41@jive.com>
Date: Tue, 22 Nov 2016 13:55:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <583482f5.46d9540a.d3af4.d038SMTPIN_ADDED_BROKEN@mx.google.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/727Ymp4dLij4jyWhkaLGFbghzS8>
Cc: tram-chairs@ietf.org, 'Dan Wing' <dan@danwing.org>, 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>
Subject: Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery
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: Tue, 22 Nov 2016 18:55:55 -0000

Le 2016-11-22 à 12:39, Karl Stahl a écrit :
> Simon> Can you please explain why a TURN server cannot return a 300 response
> to an Allocate request?
> 
> Of course the TURN server can respond with error 300, but isn't the problem
> that it then does NOT make any allocation that we can use for relaying
> traffic?

No because the client will retry its Allocate request to the unicast
address contained in the 300 response, which should then make an allocation.

> If the TURN server to be discovered is configured to return its own IP
> address in the 300 response, how can we then later use it (by sending the
> same Allocate request for relaying traffic)? The TURN server will respond
> with the 300 error response again, instead of actually making the allocation
> needed, won't it?

No, the TURN server will reply differently to requests received on its
anycast address vs its unicast address. Requests received on its anycast
address will get a 300 response, while those received on its unicast
address will get an Allocate success response.

> (I think Brandon assumes a TURN server listening to TWO IP addresses that
> can respond error 300 or make an allocation, distinguished by whether the
> request was received on its anycast address or its unicast address,

Correct.

> and I
> think Prashanth using the term "TURN anycast server" means we really have
> TWO TURN servers to play with,

That would be an equally valid deployment scenario.

> and I think others interpret the draft -10
> text as if the FIRST Allocate is responded to with error 300 and SUBSEQUENT
> Allocates actually are making allocations.

No, that would be wrong.

> The text under 3. in draft -10
> "not all TURN servers may support anycast" indicates that some Author has
> noticed the problem

No, it means that anycast may be difficult to implement depending on
specifics of the environment.

> (or is maybe here assuming that the TURN server should
> support some BGP routing setup* to get packets to the TURN server) - but
> that text is not a remedy. I can NOT SEE ANY of the above behavior being
> specified in RFC5766, can you?)
> 
> Is there any confusion around that my suggestion to use the Binding request
> (instead of the Allocate request) to get the 300 response with the IP
> address of the TURN server to use?

There is no confusion, we just don't see the point of specifying another
mechanism when we already have one that works.

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com

v2.23.0 | Report a Bug | By Email