Subject: [sipcore] WGLC: draft-ietf-sip-dual-stack

From: Adam Roach <[email-masked]>
Date: Mon, 21 Mar 2016 11:08:31 -0500

[as chair]

Today marks the start of a three-week Working Group Last Call for the 
following document:

https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/

The end of this last call is specifically intended to end on the Friday 
of the upcoming face-to-face meeting in Buenos Aires. Our plan is to ask 
the authors to incorporate any feedback received during these final 
weeks as well as comments from the face-to-face meeting into a version 
of the document that will be ready to send to the IESG.

All Working Group participants are requested to review the document and 
send comments to the SIPCORE mailing list.

/a

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Mar 2016 16:41:11 -0500

I have one comment that should be addressed before requesting 
publication of this document.

I find the formulation of section 5 confusing, and possibly misleading. 
I think it is too terse, and it unnecessarily trips up on some 
provenance pointers.

6157 doesn't defer to 6724 - it points out implementers should rely on a 
new system function call and that the function call is expected to 
implement an algorithm specified in 3484. The description of that 
algorithm is updated in 6724. But why are you pointing here anyhow? How 
is it going to help the implementer?

If you're saying the implementer needs to make sure their _own code_ 
implements what 6724 describes (as opposed to relying on a system call), 
the words in this document need to be very different.

If you're saying, instead, that they should just rely on getaddrinfo() 
after having done the SRV work and ordering to resolve A or AAAA records 
(and trust the order it returns the in), just say that.

It's really not clear _what_ in 6157 this is clarifying.

RjS

On 3/21/16 11:08 AM, Adam Roach wrote:
> The end of this last call is specifically intended to end on the 
> Friday of the upcoming face-to-face meeting in Buenos Aires. Our plan 
> is to ask the authors to incorporate any feedback received during 
> these final weeks as well as comments from the face-to-face meeting 
> into a version of the document that will be ready to send to the IESG.
>
> All Working Group participants are requested to review the document 
> and send comments to the SIPCORE mailing list.
>
> /a
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 29 Mar 2016 14:19:20 -0400

Robert Sparks <[email-masked]> writes:
> It's really not clear _what_ in 6157 [section 5 of this draft] is clarifying.

You're right.

The current section 5 is my revision of the section 5 in the -02 draft,
which is

   5.  Update to RFC 6157

   [RFC6157] defers to the Source and Destination Address Selection
   algorithms defined in [RFC6724] (the successor of [RFC3484]) when
   allowing a client to choose a specific server (c.f.  Section 5 in
   [RFC6157]).

   This document modifies the behavior of Section 5 in [RFC6157] to
   allow for an additional (and preferred) way to contact servers, as
   outlined in Section Section 4.2.  Implementations MUST use the DNS
   SRV records as described in Section Section 4.2 of this document
   first before resorting to the Source and Destination Address
   Selection algorithms defined in [RFC6724].

As far as I can tell, the goal of this section is to make it clear that
if SRV records translate a SIP domain into (e.g.) two SRV records with
different priorities, and one SRV record's target name only has IPv4
addresses and the other SRV record's target name only has IPv6
addresses, then which family of addresses is attempted first is to be
determined by priorities of the SRV records.  This being the process
described in section 4.2 of this draft.

The alternative that the implementor seems to be being warned to avoid
seems to be to put both the IPv4 and IPv6 addresses together into the
algorithm of 3484/6724 and having it order the destination addresses.

I don't think this is an update of 6157 (as the section title suggests),
as following 3263 as written gives the behavior described in section 4.2
of this draft.  And that seems to be the behavior that 6157 will result
in as well, as 6157 seems to describe putting each SRV's target into
getaddrinfo() separately to obtain the target's destination addresses.

So I would say that eliminating this section entirely would not change
the meaning of the draft.  But that leaves open what this section was
intended to accomplish.  I'll ask the other authors.

Dale

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Mar 2016 09:53:19 -0500

[as individual]

> described in section 4.2 of this draft.

I think it's somewhat more general than that, though. if you look up an 
SRV record and get multiple A and multiple AAAA records, and those 
records in turn contain multiple literal IP addresses, then you apply 
the SRV priorities first and the RFC 6724 processes second.

I think an example might help.

Let's say I look up an SRV record (_sip._tcp.example.com) and get back 
two entries:

_sip._tcp.example.com.  300 IN  SRV  10 1 5060 sip-1.example.com.
_sip._tcp.example.com.  300 IN  SRV  20 1 5060 sip-2.example.com.

So then I grab the A and AAAA records for sip-1.example.com and 
sip-2.example.com:

sip-1.example.com.    300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com.    300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com.    1800  IN  A  192.0.2.45
sip-1.example.com.    1800  IN  A  203.0.113.109
sip-1.example.com.    1800  IN  A  198.51.100.24

sip-2.example.com.    300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com.    300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com.    1800  IN  A  192.0.2.75
sip-2.example.com.    1800  IN  A  203.0.113.38
sip-2.example.com.    1800  IN  A  198.51.100.140

What I believe we're saying is that I will process these addresses in a 
batch, altogether, using RFC6724 section 6 rules:

  * 2001:0db8:58:c02::face
  * 2001:0db8:c:a06::2:cafe
  * 2001:0db8:44:204::d1ce
  * 192.0.2.45
  * 203.0.113.109
  * 198.51.100.24

And then (but only then, after I've exhausted that entire batch of 
addresses), I'll process these addresses in a batch, altogether, using 
RFC6724 section 6 rules:

  * 2001:0db8:58:c02::dead
  * 2001:0db8:c:a06::2:beef
  * 2001:0db8:44:204::c0de
  * 192.0.2.75
  * 203.0.113.38
  * 198.51.100.140

... and, most importantly, I won't mix the batches together.

/a

---

From: Robert Sparks <[email-masked]>
Date: Wed, 30 Mar 2016 10:00:39 -0500

On 3/30/16 9:53 AM, Adam Roach wrote:
> I think it's somewhat more general than that, though. if you look up 
> an SRV record and get multiple A and multiple AAAA records, and those 
Nit pick - Your sentence above starts "if you look up an SRV record"  
(that is _one_ SRV record).
There are no SRV priorities to apply (beyond the trivial "take the one I 
have").

Your example below of showing prioritizing multiple SRV records first 
using the SRV prioritization rules,
then applying the 6724 rules only when looking at a set of A/AAAA for a 
single SRV record makes sense.
> What I believe we're saying is that I will process these addresses in 
> a batch, altogether, using RFC6724 section 6 rules:
>
>   * 2001:0db8:58:c02::face

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 30 Mar 2016 17:01:30 +0200

> On 30 Mar 2016, at 16:53, Adam Roach <[email-masked]> wrote:
> 
> [as individual]
> 
> I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second.
> 
> Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries:
> 
> So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com:
> 
> What I believe we're saying is that I will process these addresses in a batch, altogether, using RFC6724 section 6 rules:
> 2001:0db8:58:c02::face
> 2001:0db8:c:a06::2:cafe
> 2001:0db8:44:204::d1ce
> 192.0.2.45
> 203.0.113.109
> 198.51.100.24
> 
> And then (but only then, after I've exhausted that entire batch of addresses), I'll process these addresses in a batch, altogether, using RFC6724 section 6 rules:
> 2001:0db8:58:c02::dead
> 2001:0db8:c:a06::2:beef
> 2001:0db8:44:204::c0de
> 192.0.2.75
> 203.0.113.38
> 198.51.100.140
> 
I agree.

This example is something we need to carry with us to the actual Happy Eyeballs draft. How do we handle 
connection setup with dual stacks with all six candidates - i.e. more than two. RFC 2782 is quite clear that 
we need to test *ALL* SRV candidates for a selected name (after load balancing decision) before proceeding to another priority.
I need to check the Happy Eyeballs RFC unless Dan Wing reads this and can comment :-)

Cheers
/O

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 30 Mar 2016 16:10:20 +0000

On Mar 30, 2016, at 12:00 PM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second.
Nit pick - Your sentence above starts "if you look up an SRV record"  (that is _one_ SRV record).
There are no SRV priorities to apply (beyond the trivial "take the one I have").

Your example below of showing prioritizing multiple SRV records first using the SRV prioritization rules,
then applying the 6724 rules only when looking at a set of A/AAAA for a single SRV record makes sense.

I agree and urging it might be tremendously useful to use such an example in the draft to unambiguously drive the point home.

-G

Let's say I look up an SRV record (_sip._tcp.example.com<http://tcp.example.com>) and get back two entries:

_sip._tcp.example.com<http://tcp.example.com>.  300 IN  SRV  10 1 5060 sip-1.example.com<http://sip-1.example.com>.
_sip._tcp.example.com<http://tcp.example.com>.  300 IN  SRV  20 1 5060 sip-2.example.com<http://sip-2.example.com>.

So then I grab the A and AAAA records for sip-1.example.com<http://sip-1.example.com> and sip-2.example.com<http://sip-2.example.com>:

sip-1.example.com<http://sip-1.example.com>.    300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com<http://sip-1.example.com>.    300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com<http://sip-1.example.com>.    300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com<http://sip-1.example.com>.    1800  IN  A  192.0.2.45
sip-1.example.com<http://sip-1.example.com>.    1800  IN  A  203.0.113.109
sip-1.example.com<http://sip-1.example.com>.    1800  IN  A  198.51.100.24

sip-2.example.com<http://sip-2.example.com>.    300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com<http://sip-2.example.com>.    300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com<http://sip-2.example.com>.    300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com<http://sip-2.example.com>.    1800  IN  A  192.0.2.75
sip-2.example.com<http://sip-2.example.com>.    1800  IN  A  203.0.113.38
sip-2.example.com<http://sip-2.example.com>.    1800  IN  A  198.51.100.140

  *   2001:0db8:58:c02::face

  *   2001:0db8:58:c02::dead

/a

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore