Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Mar 2015 11:06:58 +0000

Hi Justin,

Thanks for the comments. Please see inline [TR]

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 11:32 AM
To: [email-masked]
Subject: [tram] Comments on draft-ietf-tram-turnbis-01

better late than never:

S 6.1:
I don't think that we need to forbid using RAF with AAF. It should be possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by itself, all with the same meaning.

[TR] RAF is  comprehension-required attribute whereas AAF is comprehension-optional attribute, If client uses both RAF + AAF and the server does not understand RAF then the request could fail. I don’t see any advantage of using both RAF and AAF together.

S 7.1:
I think the client should include RAF for the bindings that it wants to keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn't know if the server supports AAF.

[TR] If AAF is used for Allocation then there is no reason why RAF should be used for the binding (server may not support RAF and it will result in failure to refresh).

S 9.1:
I don't think we want to support CreatePermissions with multiple addresses. It doesn't save anything other than 2 packets and just makes life more complicated.

[TR] Please clarify why it complicates implementation ?

S 11.1:
How would you do a ChannelBind with multiple addresses? Sent packets go to both destinations? Again, this seems complex with no good reason.

[TR] Agreed, will fix in the next reversion.

S 15.6/15.11:
It would be good to separate the RAF/AAF payload definition out so that it doesn't need to be repeated in both sections.

[TR] The payload text is not large enough for a separate section.

S 15.12:
The error code field is too small to hold error codes (8 bits). I think this should use the same structure as ERROR-CODE from 5389, but use some of the reserved bits for family.

[TR] Yes, will fix that in the next revision.

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 11:52:47 -0500

On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *From:* tram [mailto:[email-masked]] *On Behalf Of *Justin Uberti
> *Sent:* Thursday, March 26, 2015 11:32 AM
> *To:* [email-masked]
> *Subject:* [tram] Comments on draft-ietf-tram-turnbis-01
>
>
>
> better late than never:
>
>
>
> S 6.1:
>
> I don't think that we need to forbid using RAF with AAF. It should be
> possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by
> itself, all with the same meaning.
>
>
>
> [TR] RAF is  comprehension-required attribute whereas AAF is
> comprehension-optional attribute, If client uses both RAF + AAF and the
> server does not understand RAF then the request could fail. I don’t see any
> advantage of using both RAF and AAF together.
>

I agree that typically AAF will be sent by itself, but in the interest of
defining a general mechanism I don't think we should prohibit RAF + AAF.

>
>
> S 7.1:
>
> I think the client should include RAF for the bindings that it wants to
> keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn't
> know if the server supports AAF.
>
>
>
> [TR] If AAF is used for Allocation then there is no reason why RAF should
> be used for the binding (server may not support RAF and it will result in
> failure to refresh).
>

There is no server that will support AAF but not RAF.

For a dual allocation, the client should be able to refresh the v4, v6, or
both. Right now in the doc, we don't have that control. I suggest the
following:
v4 can be refreshed by sending RAF(v4).
v6 can be refreshed by sending RAF(v6).
both can be refreshed by sending RAF(v4+v6), and/or, perhaps, no RAF.

For a single allocation, I suggest we keep the existing format where
sending no RAF refreshes the allocation.

>
>
> S 9.1:
>
> I don't think we want to support CreatePermissions with multiple
> addresses. It doesn't save anything other than 2 packets and just makes
> life more complicated.
>
>
>

You now need to handle partial successes, so your error handling path is
more complicated.

But mainly, it's not clear at all why a client would use this.

>
>
> S 11.1:
>
> How would you do a ChannelBind with multiple addresses? Sent packets go to
> both destinations? Again, this seems complex with no good reason.
>
>
>
> It would be good to separate the RAF/AAF payload definition out so that it
> doesn't need to be repeated in both sections.
>
>
>

At 30 lines of text, I disagree. We are already doing this sort of thing
for XOR-PEER-ADDRESS.

>
>
> S 15.12:
>
> The error code field is too small to hold error codes (8 bits). I think
> this should use the same structure as ERROR-CODE from 5389, but use some of
> the reserved bits for family.
>
>
>
Suggestion:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Address Family                |  Rsvd  |Class|     Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Reason Phrase (variable)                                ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Mar 2015 18:39:22 +0000

Inline [TR2]

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, March 26, 2015 10:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 11:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tram] Comments on draft-ietf-tram-turnbis-01

better late than never:

S 6.1:

I agree that typically AAF will be sent by itself, but in the interest of defining a general mechanism I don't think we should prohibit RAF + AAF.

[TR2] RAF + AAF complicates server and client implementations without any benefits.

S 7.1:

For a dual allocation, the client should be able to refresh the v4, v6, or both. Right now in the doc, we don't have that control.

[TR2] The control is possible and is discussed in section 7.1

<snip>

   When refreshing a dual allocation, the client includes ADDITIONAL-
   ADDRESS-FAMILY attribute indicating the address family type that
   should be refreshed.  If no ADDITIONAL-ADDRESS-FAMILY is included
   then the request should be treated as applying to all current
   allocations.
</snip>

I suggest the following:

For a single allocation, I suggest we keep the existing format where sending no RAF refreshes the allocation.

S 9.1:

You now need to handle partial successes, so your error handling path is more complicated.

[TR2] Good point, will remove support for multiple addresses.

S 11.1:

S 15.6/15.11:

At 30 lines of text, I disagree. We are already doing this sort of thing for XOR-PEER-ADDRESS.

[TR2] Okay, will remove duplicate text.

S 15.12:

Suggestion:

[TR2] Shouldn’t it be Rsvd followed by Address family ?

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Thu, 26 Mar 2015 15:08:47 -0400

I agree that it may be difficult to handle within an implementation. 
That said, unless you're certain that no clients have implemented this 
already (it's not new in turnbis) we'll have to have an explicit 
backward compatibility mechanism. What do you propose for that?

I agree that we shouldn't add multi-address support to ChannelBind 
requests, though, since it doesn't already exist there.

--Brandon

On 03/26/2015 02:39 PM, Tirumaleswar Reddy (tireddy) wrote:
>     addresses. It doesn't save anything other than 2 packets and just
>     makes life more complicated.
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 16:55:00 -0500

OK, this was an oversight on my part. As long as we return 400 if any
addresses are busted (as currently indicated in S 9.2), this should work
fine - v4 permissions set for the v4 allocation, v6 permissions set for v6
allocation.

On Thu, Mar 26, 2015 at 2:08 PM, Brandon Williams <
[email-masked]> wrote:

> I agree that it may be difficult to handle within an implementation. That
> said, unless you're certain that no clients have implemented this already
> (it's not new in turnbis) we'll have to have an explicit backward
> compatibility mechanism. What do you propose for that?
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 17:02:02 -0500

On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Inline [TR2]
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Thursday, March 26, 2015 10:23 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [email-masked]
> *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01
>
>
>
>
>
>
>

I think it makes it easier to reason about what these attributes actually
do. Server needs to handle RAF anyway.

That said, I don't feel super strongly about this.

> both. Right now in the doc, we don't have that control.
>
>
>

It doesn't say how to only refresh v4, or only refresh v6, in a dual
allocation.

> [TR] Yes, will fix that in the next revision.
Then it won't be byte-aligned, which seems bad.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 27 Mar 2015 02:16:54 +0000

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, March 27, 2015 3:32 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Inline [TR2]

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 26, 2015 10:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

better late than never:

S 6.1:

I think it makes it easier to reason about what these attributes actually do. Server needs to handle RAF anyway.

S 7.1:

<snip>

It doesn't say how to only refresh v4, or only refresh v6, in a dual allocation.

[TR3] It’s explained in the first line; client refreshes v4 by including AAF (v4), client refreshes v6 by including AAF (v6).

-Tiru

I suggest the following:

S 9.1:

S 11.1:

S 15.6/15.11:

S 15.12:

Suggestion:

---

From: Justin Uberti <[email-masked]>
Date: Thu, 26 Mar 2015 23:00:01 -0500

On Thu, Mar 26, 2015 at 9:16 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *Sent:* Friday, March 27, 2015 3:32 AM
>
> [TR3] It’s explained in the first line; client refreshes v4 by including
> AAF (v4), client refreshes v6 by including AAF (v6).
>
>
>

OK, I get it now. But I think that is super confusing - the semantics are
totally different than for ALLOCATE.

In ALLOCATE, no AAF means "v4 only", and v6 AAF means "v4+v6".
In REFRESH, no AAF means "v4+v6", and v6 AAF means "v6 only".

Part of the problem is that AAF, by its use of the work "additional",
implies that the specified address family is in addition to something else.
Here, we're not doing that, which is why it is confusing.

I think that REFRESH should work as follows:
- REFRESH with no attributes refreshes everything, regardless of allocation
type
- REFRESH with specific RAF refreshes only the specific allocation if it
exists, or otherwise fails
- REFRESH with any AAF fails because it is not well-defined

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 26 Mar 2015 21:42:32 -0700

> - REFRESH with any AAF fails because it is not well-defined

this behaviour is not compatible with older (RFC5766-compliant)
servers that do not understand AAF. They will treat option 1 and
option 3 as the same case.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Mar 2015 00:07:51 -0500

Sure, I am just saying that we shouldn't recommend that clients send AAF in
Refresh requests.

Send nothing if you want to refresh everything (or are not using a dual
allocation); send RAF if you want to refresh (or kill) just one part of a
dual allocation.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 27 Mar 2015 05:29:31 +0000

Inline [TR4]

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, March 27, 2015 9:30 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

On Thu, Mar 26, 2015 at 9:16 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

better late than never:

S 6.1:

S 7.1:

<snip>

OK, I get it now. But I think that is super confusing - the semantics are totally different than for ALLOCATE.

[TR] Yes.

Part of the problem is that AAF, by its use of the work "additional", implies that the specified address family is in addition to something else. Here, we're not doing that, which is why it is confusing.

I think that REFRESH should work as follows:
- REFRESH with no attributes refreshes everything, regardless of allocation type
- REFRESH with specific RAF refreshes only the specific allocation if it exists, or otherwise fails
- REFRESH with any AAF fails because it is not well-defined

[TR4] There are two reasons for using AAF in Refresh request. One is that http://tools.ietf.org/html/rfc6156#section-5.1 explains RAF cannot be used in Refresh request and the other is to use the same attribute in both Allocate and Refresh.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 27 Mar 2015 05:38:27 +0000

The client includes AAF in Refresh only if dual allocation is successful which means client when it sends Refresh knows if server supports AAF or not.

-Tiru

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: Friday, March 27, 2015 10:13 AM
> To: Justin Uberti
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]
> this behaviour is not compatible with older (RFC5766-compliant) servers that do
> not understand AAF. They will treat option 1 and option 3 as the same case.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Mar 2015 09:50:40 -0500

Agreed, but I think using AAF in Refresh has confusing semantics, since
they are different from Allocate. Restating from my previous message:

In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6".
In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only".

Compare this to how RAF could be handled:

In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only".
In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only".

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> The client includes AAF in Refresh only if dual allocation is successful
> which means client when it sends Refresh knows if server supports AAF or
> not.
>
> -Tiru
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 28 Mar 2015 02:08:09 +0000

Hi Justin,

The problem is RFC 6156 says that RAF must not be used in Refresh request, that is one of the reasons for using AAF in Refresh.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, March 27, 2015 8:21 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

Agreed, but I think using AAF in Refresh has confusing semantics, since they are different from Allocate. Restating from my previous message:

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
The client includes AAF in Refresh only if dual allocation is successful which means client when it sends Refresh knows if server supports AAF or not.

-Tiru

> From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >

---

From: Justin Uberti <[email-masked]>
Date: Sat, 28 Mar 2015 17:47:01 -0700

We are obsoleting 6156, so we can say whatever we want - especially in the
case of dual allocations.

On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi Justin,
>
>
>
> The problem is RFC 6156 says that RAF must not be used in Refresh request,
> that is one of the reasons for using AAF in Refresh.
>
>
>
> -Tiru
>
>
>
> *Sent:* Friday, March 27, 2015 8:21 PM
> *Cc:* Oleg Moskalenko; [email-masked]
>