Subject: Re: [tram] Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT)

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 1 Sep 2016 11:41:38 +0200

Hi Tiru,

see below.

> Am 01.09.2016 um 04:52 schrieb Tirumaleswar Reddy (tireddy) <[email-masked]>:
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind [mailto:[email-masked]]
>> Sent: Wednesday, August 31, 2016 11:21 PM
>> To: The IESG <[email-masked]>
>> Cc: [email-masked]; Simon Perreault
>> <[email-masked]>; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-05:
>> (with COMMENT)
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-tram-turn-mobility-05: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Is the following scenario worth to be discussed in the doc?
>> 
>> A client receives a MOBILITY-TICKET from the server but when it tries to send
>> a Refresh Request the server ignors the ticket and sets up a new association
>> (maybe because the server seemlessly migrated to a machine that does not
>> support/understand MOBILITY-TICKETs or because of policy
>> reasons) and therefore also does not send a new MOBILITY-TICKET back. I
>> guess in this case the client would probably still want to communication with
>> the destination server and just start a new transport connection, right?
> 
> Yes, server will throw an error and client will have to start a new allocation.
> It's an corner case, but probably worth discussing. 
> 
> I can add the following lines to Section 3.2.2: 
> 
> If the server configuration changes to forbid mobility or the server transparently fails-over to another server instance that does support MOBILITY-TICKET then the server rejects the Refresh request with a  Mobility Forbidden error code and the client starts afresh with a new allocation.

That’s not quite the case I talking about. What if the new server doesn’t even implement MOBILITY-TICKETs. That means it can not send a Mobility Forbidden error code.

Mirja

> -Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 1 Sep 2016 09:50:35 +0000

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Thursday, September 1, 2016 3:12 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-
> 05: (with COMMENT)
> 
> Hi Tiru,
> 
> see below.
> 
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> A client receives a MOBILITY-TICKET from the server but when it tries
> >> to send a Refresh Request the server ignors the ticket and sets up a
> >> new association (maybe because the server seemlessly migrated to a
> >> machine that does not support/understand MOBILITY-TICKETs or because
> >> of policy
> >> reasons) and therefore also does not send a new MOBILITY-TICKET back.
> >> I guess in this case the client would probably still want to
> >> communication with the destination server and just start a new transport
> connection, right?
> >
> > If the server configuration changes to forbid mobility or the server
> transparently fails-over to another server instance that does support
> MOBILITY-TICKET then the server rejects the Refresh request with a  Mobility
> Forbidden error code and the client starts afresh with a new allocation.
> 
> That’s not quite the case I talking about. What if the new server doesn’t even
> implement MOBILITY-TICKETs. That means it can not send a Mobility
> Forbidden error code.

Got it. In this case server will ignore the attribute and will try to retrieve the 5-tuple from the packet
to identify an associated allocation, look-up fails and the server would return 437 (Allocation Mismatch) error.

-Tiru

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 1 Sep 2016 12:08:15 +0200

Hi,

see below. 

> Am 01.09.2016 um 11:50 schrieb Tirumaleswar Reddy (tireddy) <[email-masked]>:
> 

Ah okay. In this case it’s actually fine.

Mirja