Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Jan 2013 15:51:10 +0000

On Dec 17, 2012, at 10:08 AM, Ted Lemon <[email-masked]> wrote:
> Based on some feedback from the working group, we have a new version of the triggered-reconfigure document that I think addresses the concerns that were raised during the previous last call.   For those who tuned in late, this document describes a mechanism for triggering a reconfigure when a relay agent is sending some relay options to the server, and the information in those options has changed (e.g., the RSOO, or Leaf's RADIUS options).
> 
> So this is a second last call, so the working group can review the changes.   The diffs are here:

We got two responses to this WGLC.   I'm also in favor, so that makes three, which isn't enough to advance the document.

Bernie, have your objections to the previous draft been corrected in the current draft?   Others, could you please respond to this WGLC if you think the document should advance?   Kim Kinnear, Bud Millwood, Tomek Mrugalski, Tina Tsou and Andre Kostur commented on the document, but didn't say anything in response to the WGLC.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 9 Jan 2013 09:09:55 -0800

Thank-you for the reminder... my turn to have been on vacation.

I support this draft for advancement.

On Mon, Jan 7, 2013 at 7:51 AM, Ted Lemon <[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

--
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jan 2013 04:56:37 +0000

While this now does better address my earlier comments, I have more.

What are the retransmission parameters / algorithm for the Reconfigure-Request? (See RFC 3315 as to the algorithm there and the parameters that are usually specified).

As there is no direct response to the Reconfigure-Request (such as a Reply), but instead the Relay knows if it was accepted by the fact that it gets a (Relay-Reply containing) a Reconfigure (for the client(s)).

So, I assume that the Relay might try the Reconfigure-Request again if it gets no Reconfigure? Perhaps the Reconfigure-Request was "lost" in the network or the server had no resources to process the packet at the time it was received?

Also, what happens if the server has no record of one or more client's in the Reconfigure-Request or has not negotiated for Reconfigure support with that client? As it can't generate a Reconfigure to the client, how does the Relay know this and stop retrying?

Or, are you really intending this to be a 'fire once' and hope for the best?

Perhaps there might be some value in having some kind of Reply message as then the server could say, "OK, starting reconfigure" or "OK, but failed on some clients", or "Not allowed" or whatever? (This also has potential benefit for the server to rate limit Reconfigures, as mentioned below as the time before a 'Reconfigure' message is seen by the Relay could be variable and thus having an explicit Reply can be a win.)

I also question the requirement that the link-address cannot be 0. While I don't know if it was ever used, I have heard of cases where people had wanted to have no link-address (0::0) because they were going to use other information in Relay-Forw to determine the client's location. And this then required that other information to be included (such as Interface-ID, etc.). I think the Relay should include those items in the Reconfigure-Request that it would include if it were relaying a client request -- the link-address is just one of those items. Thus, I think you should just drop the following paragraph in section 3 (the earlier requirement that it is the "equivalent" to what was used for Relay-Forw's for the client is sufficient!):

   The relay agent MUST NOT use the IPv6 unspecified address (0::0) in
   this option.  The server MUST discard any Reconfigure Request message
   containing a Link Address Option that carries the unspecified
   address.

And, perhaps we leave it as a server issue or undefined, but there might also be a rate limiting issue to avoid a flood of Reconfigures? The Relay has some ability to do that in how many client identifiers it includes in a Reconfigure-Request and how many Reconfigure-Request(s) it may send at what rate. If the Relay has 10,000 clients that all used the RSOO options that changed, it would likely not want to have all 10,000 reconfigure 'at once'.

- Bernie

---

From: <[email-masked]>
Date: Wed, 16 Jan 2013 14:01:08 +0100

Dear Bernie,

Many thanks for the review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:[email-masked]] 
>Envoyé : lundi 14 janvier 2013 05:57
>À : dhc WG
>Cc : BOUCADAIR Mohamed OLNC/OLN; POUGNARD Xavier OLNC/OLN
>Objet : RE: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02
>
>What are the retransmission parameters / algorithm for the 
>Reconfigure-Request? (See RFC 3315 as to the algorithm there 
>and the parameters that are usually specified).
>
>As there is no direct response to the Reconfigure-Request 
>(such as a Reply), but instead the Relay knows if it was 
>accepted by the fact that it gets a (Relay-Reply containing) a 
>Reconfigure (for the client(s)).
>
>So, I assume that the Relay might try the Reconfigure-Request 
>again if it gets no Reconfigure? Perhaps the 
>Reconfigure-Request was "lost" in the network or the server 
>had no resources to process the packet at the time it was received?
>
>Also, what happens if the server has no record of one or more 
>client's in the Reconfigure-Request or has not negotiated for 
>Reconfigure support with that client? As it can't generate a 
>Reconfigure to the client, how does the Relay know this and 
>stop retrying?
>

Med: The scheme I had in mind is re-transmission is triggered by out-of-band mechanism controlling the relay. I do agree this may not be generic and as such I see a value in defining a re-transmission procedure in the relay itself (the default values for the retrans parameters would be identical to those in RFC5007 + relay monitors the reconfigure messages received from the server or the expected request from the client). The re-transmission procedure can be disabled by configuration if an out-of-band mechanism is used. If retrans is enabled in the relay, retrans parameters should be configurable.

If you agree with the proposed logic, I can propose some text in this direction. 

>
>Perhaps there might be some value in having some kind of Reply 
>message as then the server could say, "OK, starting 
>reconfigure" or "OK, but failed on some clients", or "Not 
>allowed" or whatever? (This also has potential benefit for the 
>server to rate limit Reconfigures, as mentioned below as the 
>time before a 'Reconfigure' message is seen by the Relay could 
>be variable and thus having an explicit Reply can be a win.)

Med: Defining an explicit response to the reconfigure-request is imho redundant with the receipt of a reconfigure message from the server (or receipt of a request from the client to request for the updated config). 

>
>
>I also question the requirement that the link-address cannot 
>be 0. While I don't know if it was ever used, I have heard of 
>cases where people had wanted to have no link-address (0::0) 
>because they were going to use other information in Relay-Forw 
>to determine the client's location. And this then required 
>that other information to be included (such as Interface-ID, 
>etc.). I think the Relay should include those items in the 
>Reconfigure-Request that it would include if it were relaying 
>a client request -- the link-address is just one of those 
>items. Thus, I think you should just drop the following 
>paragraph in section 3 (the earlier requirement that it is the 
>"equivalent" to what was used for Relay-Forw's for the client 
>is sufficient!):
>

Med: Isn't odd to include a "Link Address Option" which carries a link-address set to "0::0"? 
If you think there is a value to cover the scenario you described, wouldn't be better to relax the text to explicitly allow the use of Interface-ID if link-address =0::0 (but no "Link Address Option" is included). In other words, my proposal is:
* maintain the definition of "Link Address Option" as it is in the current version.
* if link-address=0:0, update the validation text to include to require including Interface-ID.

Do you agree/disagree with this proposition?

>
>And, perhaps we leave it as a server issue or undefined, but 
>there might also be a rate limiting issue to avoid a flood of 
>Reconfigures? The Relay has some ability to do that in how 
>many client identifiers it includes in a Reconfigure-Request 
>and how many Reconfigure-Request(s) it may send at what rate. 
>If the Relay has 10,000 clients that all used the RSOO options 
>that changed, it would likely not want to have all 10,000 
>reconfigure 'at once'.

Med: Would you be fine If the text is updated to reflect the following: 
* The server MUST implement a local policy to rate-limit reconfigure messages triggered by a reconfigure-request. 
* The relay SHOULD be configured with the maximum number of distinct client identifiers to be included in the same reconfigure-request message.

>>> Based on some feedback from the working group, we have a 
>new version of the triggered-reconfigure document that I think 
>addresses the concerns that were raised during the previous 
>last call.   For those who tuned in late, this document 
>describes a mechanism for triggering a reconfigure when a 
>relay agent is sending some relay options to the server, and 
>the information in those options has changed (e.g., the RSOO, 
>or Leaf's RADIUS options).
>>>
>> We got two responses to this WGLC.   I'm also in favor, so 
>that makes three, which isn't enough to advance the document.
>>
>> Bernie, have your objections to the previous draft been 
>corrected in the current draft?   Others, could you please 
>respond to this WGLC if you think the document should advance? 
>  Kim Kinnear, Bud Millwood, Tomek Mrugalski, Tina Tsou and 
>Andre Kostur commented on the document, but didn't say 
>anything in response to the WGLC.
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Jan 2013 15:10:11 +0000

Hi:

1. I think the link-address option should always be present, even if it has 0::0. Just remove that one paragraph about it not being 0::0.

2. Whether interface-id and other Relay options are present is worth discussing. The main reason for including interface-id in Relay-Forw/Relay-Reply is that it is sent back to Relay. That is not necessary in this case (as there is no Reply). I guess my choice would be silent as to the issue -- or to indicate that Relay options normally included in the Relay-Forw MAY (SHOULD?) be added. (See #4 which may suggest making this a MUST or SHOULD.)

3. Just limiting the number of client-ids in a Reconfigure-Request is insufficient as the Relay can just send more packets. It is really the "total" that is important. Rate limiting the packets is also important -- Relay shouldn't blast out 100 packets at once.

4. If the server rate limits the reconfigures, the Relay may have to wait a long time (many 10s of seconds or minutes) if a lot of Reconfigures are requested. This may complicate the any retransmissions of the Reconfigure-Request or result in duplicated requests (not necessarily the messages, but the clients being reconfigured). I still think having a Reply has some value, IMHO.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2013 8:01 AM
To: Bernie Volz (volz); dhc WG
Cc: POUGNARD Xavier OLNC/OLN
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02

Dear Bernie,

Please see inline.

Cheers,
Med 

>De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : lundi 14 
>janvier 2013 05:57 À : dhc WG Cc : BOUCADAIR Mohamed OLNC/OLN; POUGNARD 
>Xavier OLNC/OLN Objet : RE: [dhcwg] WGLC: 
>draft-ietf-dhc-triggered-reconfigure-02
>
>Reconfigure-Request? (See RFC 3315 as to the algorithm there and the 
>parameters that are usually specified).
>
>As there is no direct response to the Reconfigure-Request (such as a 
>Reply), but instead the Relay knows if it was accepted by the fact that 
>it gets a (Relay-Reply containing) a Reconfigure (for the client(s)).
>
>So, I assume that the Relay might try the Reconfigure-Request again if 
>it gets no Reconfigure? Perhaps the Reconfigure-Request was "lost" in 
>the network or the server had no resources to process the packet at the 
>time it was received?
>
>Also, what happens if the server has no record of one or more client's 
>in the Reconfigure-Request or has not negotiated for Reconfigure 
>support with that client? As it can't generate a Reconfigure to the 
>client, how does the Relay know this and stop retrying?
>

>
>Perhaps there might be some value in having some kind of Reply message 
>as then the server could say, "OK, starting reconfigure" or "OK, but 
>failed on some clients", or "Not allowed" or whatever? (This also has 
>potential benefit for the server to rate limit Reconfigures, as 
>mentioned below as the time before a 'Reconfigure' message is seen by 
>the Relay could be variable and thus having an explicit Reply can be a 
>win.)

>
>
>I also question the requirement that the link-address cannot be 0. 
>While I don't know if it was ever used, I have heard of cases where 
>people had wanted to have no link-address (0::0) because they were 
>going to use other information in Relay-Forw to determine the client's 
>location. And this then required that other information to be included 
>(such as Interface-ID, etc.). I think the Relay should include those 
>items in the Reconfigure-Request that it would include if it were 
>relaying a client request -- the link-address is just one of those 
>items. Thus, I think you should just drop the following paragraph in 
>section 3 (the earlier requirement that it is the "equivalent" to what 
>was used for Relay-Forw's for the client is sufficient!):
>

>
>And, perhaps we leave it as a server issue or undefined, but there 
>might also be a rate limiting issue to avoid a flood of Reconfigures? 
>The Relay has some ability to do that in how many client identifiers it 
>includes in a Reconfigure-Request and how many Reconfigure-Request(s) 
>it may send at what rate.
>If the Relay has 10,000 clients that all used the RSOO options that 
>changed, it would likely not want to have all 10,000 reconfigure 'at 
>once'.

>describes a mechanism for triggering a reconfigure when a relay agent 
>is sending some relay options to the server, and the information in 
>those options has changed (e.g., the RSOO, or Leaf's RADIUS options).
>>>
>  Kim Kinnear, Bud Millwood, Tomek Mrugalski, Tina Tsou and Andre 
>Kostur commented on the document, but didn't say anything in response 
>to the WGLC.
>>