Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3
Ben Campbell has entered the following ballot position for
draft-ietf-dhc-relay-port-08: Discuss

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-dhc-relay-port/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(I want to "discuss" the following  DISCUSS point. If the answer is that this
is by design, and the working group thinks that the operational aspects are
reasonable, then I will clear.)

This extension places normative requirements on any upstream server or relay,
which may or may not implement this spec.  It further appears that if you try
to use this extension without that support, things will break. That seems to
require at least an update to the DCHP and DCHPv6 RFCs[1], and some method of
discovery or fallback would be helpful. Section 5.4 discusses this a little
bit, but I think it needs to talk about what to do when things fail. "Turn off
the feature if you don't get DHCP responses" doesn't seem satisfying.

[1] I see 3.1 and 3.2 make changes to 2131 and 3315, so it seems an "UPDATES...
" tag is needed one way or another.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-1, last paragraph: It seems like the 2119 keywords here would be better placed
in the later sections about relay and server behavior. I suggest moving them
there, and making the introductory language non-normative.

- 3.1 and 3.2: I am surprised not to see 2119 keywords in the language added to
2131 and 3315:

-8: This spec adds the ability to direct dhcp responses to non-standard ports.
If the working group believes that does not affect the security considerations,
please describe the rational. (I'm not saying that I think there's a problem,
but I think the burden is on the working group to explain why they think there
is not.)


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ted Lemon
Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Hi Ben,

Thanks for the review.

I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
If an operator wants to turn on this feature on a relay(s), he/she can find out if the
server or upstream relay supports this or not, and it’s easy to disable this feature
if it does not work (could also be bugs in software).

Also, the configuration of the feature is on the relay, the upstream relays and
server as long as has the software upgraded, they don’t need configuration. This
is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
out if server supports that or not, and as soon as the server has the updated software,
it would automatically supports this.

For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:

        "We’ve already had this discussion and debate. It only UPDATES if you want to
        use this new capabilities, we don’t have a flag for that. UPDATES usually implies
        that you must do that."


Best Regards,
- Naiming

> On Nov 29, 2017, at 1:19 PM, Ted Lemon <[hidden email]> wrote:
>
> Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3
In reply to this post by Ted Lemon
Hi Ted,

It explicitly proposes changes to changes language to 2131 and 3315. I’m not sure how to read that in any other way than updating 2131 and 3315.

Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the creation of the draft would not assume it to be general purpose.

I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it would help to strengthen the language in 5.4 to make it clear what will break if people get this wrong.

Paragraph 2 of that section seems vague about when such a relay might choose a DHCP vs non-DHCP port. Is there some expectation that the relay would listen on both ports, in case of stray responses?

Ben.

> On Nov 29, 2017, at 3:19 PM, Ted Lemon <[hidden email]> wrote:
>
> Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.
>


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3
In reply to this post by Naiming Shen (naiming)


> On Nov 29, 2017, at 6:10 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>
>
> Hi Ben,
>
> Thanks for the review.
>
> I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
> If an operator wants to turn on this feature on a relay(s), he/she can find out if the
> server or upstream relay supports this or not, and it’s easy to disable this feature
> if it does not work (could also be bugs in software).
Please see my comments to Ted (which crossed in the mail with your message)

>
> Also, the configuration of the feature is on the relay, the upstream relays and
> server as long as has the software upgraded, they don’t need configuration. This
> is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
> the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
> out if server supports that or not, and as soon as the server has the updated software,
> it would automatically supports this.

Sure, but “as long as the the software has been upgraded” is an important precondition.

>
> For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:
>
> "We’ve already had this discussion and debate. It only UPDATES if you want to
> use this new capabilities, we don’t have a flag for that. UPDATES usually implies
> that you must do that.”

I don’t agree with that characterization of UPDATES. An update that adds an optional feature is still an update. Whether or not implementations are required to support it depends on the specifics of the update. The main purpose is that readers of the original RFC know they need to pay attention to the new one.

>
>
> Best Regards,
> - Naiming
>
>> On Nov 29, 2017, at 1:19 PM, Ted Lemon <[hidden email]> wrote:
>>
>> Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.
>>
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)
Ben,

Inline, 
On Nov 29, 2017, at 4:19 PM, Ben Campbell <[hidden email]> wrote:



On Nov 29, 2017, at 6:10 PM, Naiming Shen (naiming) <[hidden email]> wrote:


Hi Ben,

Thanks for the review.

I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
If an operator wants to turn on this feature on a relay(s), he/she can find out if the
server or upstream relay supports this or not, and it’s easy to disable this feature
if it does not work (could also be bugs in software).

Please see my comments to Ted (which crossed in the mail with your message)

Just saw that. Will add stronger wording on the section 5.4. to warn operational
users on this issue.



Also, the configuration of the feature is on the relay, the upstream relays and
server as long as has the software upgraded, they don’t need configuration. This
is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
out if server supports that or not, and as soon as the server has the updated software,
it would automatically supports this.

Sure, but “as long as the the software has been upgraded” is an important precondition.

True. But I’m also saying this draft is following the same model as the other relay-options.
If an operation is relying on the ‘Subscribe-ID’ to be returned, and the server has not
yet supported this in software, it is broken in the DHCP chain and the relay can not
function correctly also. We’ll put stronger wording in the draft.



For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:

"We’ve already had this discussion and debate. It only UPDATES if you want to
use this new capabilities, we don’t have a flag for that. UPDATES usually implies
that you must do that.”

I don’t agree with that characterization of UPDATES. An update that adds an optional feature is still an update. Whether or not implementations are required to support it depends on the specifics of the update. The main purpose is that readers of the original RFC know they need to pay attention to the new one.

I’ll defer this to the chairs.

Best Regards,
- Naiming




Best Regards,
- Naiming

On Nov 29, 2017, at 1:19 PM, Ted Lemon <[hidden email]> wrote:

Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ted Lemon
In reply to this post by Ben Campbell-3
On Nov 29, 2017, at 7:15 PM, Ben Campbell <[hidden email]> wrote:
Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the creation of the draft would not assume it to be general purpose.

Suppose they did.   What would go wrong?

I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it would help to strengthen the language in 5.4 to make it clear what will break if people get this wrong.

Why would the owner or operator of the cable modem configure it to use a different DHCP port?

That said, I agree that this shouldn't be stated as updates to documents it's not updating.   This is an extension, not an update.   So sections 3.1 and 3.2 should really be stated as additional behavior for conforming implementations, not as updates to the base documents.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Have a change in section 3.1, 3.2 and 5.4, please review to see if this is enough.
Diff PDF enclosed:

Best Regards,
- Naiming

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

relay-port-diff-08-09.pdf (364K) Download Attachment
ATT00001.htm (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ted Lemon
What I would suggest is that you actually just specify the behavior and not specify an update to the document.   Changing the wording around the update isn't solving the problem.   So e.g. in section 3.1:

OLD:
   This specification adds the following extension to the above
   paragraph.

      DHCP messages from a relay agent to a server are sent to the 'DHCP
      server' port (67), and the UDP source port it uses can be any
      valid UDP port available in the relay system, including the DHCP
      port 67.  The default port number is 67 if there is no explicit
      configuration for the generalized source UDP port extension for
      DHCP relay.

NEW:
Relay agents implementing this specification may be configured instead to send to a port number other than 67.   This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is configured to listen on the same port.

And then do the same with section 3.2.

This makes the text a lot easier to follow, and doesn't imply that this document is in any way updating the base documents.



_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Ted, and others,

Note that the server does not need to listen on this port, but it needs to send back
the relay-reply to that port, so I modified your text a little.
the HTML diff is enclosed.

Best Regards,
- Naiming


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

draft-ietf-dhc-relay-port-09-from-8.diff.html (58K) Download Attachment
ATT00001.htm (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ted Lemon
On Nov 29, 2017, at 9:01 PM, Naiming Shen (naiming) <[hidden email]> wrote:
Note that the server does not need to listen on this port, but it needs to send back
the relay-reply to that port, so I modified your text a little.
the HTML diff is enclosed.

Oops, sorry, it's been a while since I was following this closely.  So the text should say something more like this:

Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port.  This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.



_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Cool. new diff of html enclosed.

Best Regards,
- Naiming


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

draft-ietf-dhc-relay-port-09-from-8.diff.html (58K) Download Attachment
ATT00001.htm (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3
In reply to this post by Ted Lemon
First, as I said in my discuss point, I planned to clear after a round of discussion. I think the discussion is on the right track, so I will clear.

More inline:

> On Nov 29, 2017, at 6:41 PM, Ted Lemon <[hidden email]> wrote:
>
> On Nov 29, 2017, at 7:15 PM, Ben Campbell <[hidden email]> wrote:
>> Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the creation of the draft would not assume it to be general purpose.
>
> Suppose they did.   What would go wrong?

I thought you were using the idea that this was not general purpose as an argument about why we don’t need to worry about people trying to mix relays that implement this with other elements that do not :-)

>
>> I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it would help to strengthen the language in 5.4 to make it clear what will break if people get this wrong.
>
> Why would the owner or operator of the cable modem configure it to use a different DHCP port?

Sorry, the cable modem comment was merely an aside, not a material part of my argument. I recognize there’s no real reason for it to use this extension.

>
> That said, I agree that this shouldn't be stated as updates to documents it's not updating.   This is an extension, not an update.   So sections 3.1 and 3.2 should really be stated as additional behavior for conforming implementations, not as updates to the base documents.
>

Thanks!

Ben.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3
In reply to this post by Naiming Shen (naiming)
Thanks for the updates.

In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?

Thanks!

Ben.

> On Nov 29, 2017, at 8:22 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>
>
> Cool. new diff of html enclosed.
>
> Best Regards,
> - Naiming
>
> <draft-ietf-dhc-relay-port-09-from-8.diff.html>
>
>
>> On Nov 29, 2017, at 6:17 PM, Ted Lemon <[hidden email]> wrote:
>>
>> On Nov 29, 2017, at 9:01 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>>> Note that the server does not need to listen on this port, but it needs to send back
>>> the relay-reply to that port, so I modified your text a little.
>>> the HTML diff is enclosed.
>>
>> Oops, sorry, it's been a while since I was following this closely.  So the text should say something more like this:
>>
>> Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port.  This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.
>>
>>
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Hi Ben,


> On Nov 29, 2017, at 6:30 PM, Ben Campbell <[hidden email]> wrote:
>
> Thanks for the updates.
>
> In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?

I think it's up to implementation. It is possible to listen on both ports, especially in ipv4 DHCP,
it has to listen on port 67 for client DHCP messages. For an implementation, if it configures
the relay-port feature and but receives the server relay-reply message on port 67, should it
drop or should it just log an error and keep handling this? either way is fine I think.

But from the large scale relay box implementation case, say there are three relay processes handling
the DHCP relay on the same box, there can be a default/central DHCP process just to receive on the
port 67, then dispatch the work to one of the relay-agents in round-robin fashion. In such a setup, if the
server does not support this feature, and it sends back on port 67, this central DHCP process may not
have information on which relay-agent to give it to. If it does, then that defeats the purpose of multiple
relay-agents on this box.

So to your question, it depends on the implementation and operational needs.

thanks.
- Naiming

>
> Thanks!
>
> Ben.
>
>> On Nov 29, 2017, at 8:22 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>>
>>
>> Cool. new diff of html enclosed.
>>
>> Best Regards,
>> - Naiming
>>
>> <draft-ietf-dhc-relay-port-09-from-8.diff.html>
>>
>>
>>> On Nov 29, 2017, at 6:17 PM, Ted Lemon <[hidden email]> wrote:
>>>
>>> On Nov 29, 2017, at 9:01 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>>>> Note that the server does not need to listen on this port, but it needs to send back
>>>> the relay-reply to that port, so I modified your text a little.
>>>> the HTML diff is enclosed.
>>>
>>> Oops, sorry, it's been a while since I was following this closely.  So the text should say something more like this:
>>>
>>> Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port.  This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.
>>>
>>>
>>
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell-3


> On Nov 29, 2017, at 9:00 PM, Naiming Shen (naiming) <[hidden email]> wrote:
>
>
> Hi Ben,
>
>
>> On Nov 29, 2017, at 6:30 PM, Ben Campbell <[hidden email]> wrote:
>>
>> Thanks for the updates.
>>
>> In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?
>
> I think it's up to implementation. It is possible to listen on both ports, especially in ipv4 DHCP,
> it has to listen on port 67 for client DHCP messages. For an implementation, if it configures
> the relay-port feature and but receives the server relay-reply message on port 67, should it
> drop or should it just log an error and keep handling this? either way is fine I think.
>
> But from the large scale relay box implementation case, say there are three relay processes handling
> the DHCP relay on the same box, there can be a default/central DHCP process just to receive on the
> port 67, then dispatch the work to one of the relay-agents in round-robin fashion. In such a setup, if the
> server does not support this feature, and it sends back on port 67, this central DHCP process may not
> have information on which relay-agent to give it to. If it does, then that defeats the purpose of multiple
> relay-agents on this box.
>
> So to your question, it depends on the implementation and operational needs.
Thanks, and that seems reasonable. But I’m still unclear on the intent of that paragraph. Can you elaborate?

Ben.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Ha, I missed that. This paragraph I took from AD review suggested text, and
it just means the implementation can have configuration knob to either enable
this feature by specifying a non-DHCP port number or disable that and leave
the port number to be at default:-)

I’ll modify the text so that is more readable. thanks.

- Naiming

On Nov 29, 2017, at 8:02 PM, Ben Campbell <[hidden email]> wrote:



On Nov 29, 2017, at 9:00 PM, Naiming Shen (naiming) <[hidden email]> wrote:


Hi Ben,


On Nov 29, 2017, at 6:30 PM, Ben Campbell <[hidden email]> wrote:

Thanks for the updates.

In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?

I think it's up to implementation. It is possible to listen on both ports, especially in ipv4 DHCP,
it has to listen on port 67 for client DHCP messages. For an implementation, if it configures
the relay-port feature and but receives the server relay-reply message on port 67, should it
drop or should it just log an error and keep handling this? either way is fine I think.

But from the large scale relay box implementation case, say there are three relay processes handling
the DHCP relay on the same box, there can be a default/central DHCP process just to receive on the
port 67, then dispatch the work to one of the relay-agents in round-robin fashion. In such a setup, if the
server does not support this feature, and it sends back on port 67, this central DHCP process may not
have information on which relay-agent to give it to. If it does, then that defeats the purpose of multiple
relay-agents on this box.

So to your question, it depends on the implementation and operational needs.

Thanks, and that seems reasonable. But I’m still unclear on the intent of that paragraph. Can you elaborate?

Ben.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ted Lemon
I'm sorry to belabor this, but I'm realizing that there's a bit of ambiguity in the new text in that there are actually two types of messages sent by relays: server-direction and client-direction.   The current text doesn't make that distinction:

Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.

I do not know what the actual intention is—if all relay messages toward clients come from port 67, there's no problem.   All relay messages to clients _have_ to come from port 67.   It could be that you intend relay messages from relays to relays in the direction of clients to come from a different source port.   But right now I think that the text is just about messages from relays to relays or servers, in the direction of servers.   Is that correct?   If so, the easiest change would be something like this:

Relay agents implementing this specification may be configured instead to use a source port number other than 67 when relaying messages toward servers, and to receive responses toward clients on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Naiming Shen (naiming)

Ted,

NP. Sounds reasonable. I can adapt this in the next update. Thanks.

- Naiming

On Nov 30, 2017, at 4:36 AM, Ted Lemon <[hidden email]> wrote:

I'm sorry to belabor this, but I'm realizing that there's a bit of ambiguity in the new text in that there are actually two types of messages sent by relays: server-direction and client-direction.   The current text doesn't make that distinction:

Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.

I do not know what the actual intention is—if all relay messages toward clients come from port 67, there's no problem.   All relay messages to clients _have_ to come from port 67.   It could be that you intend relay messages from relays to relays in the direction of clients to come from a different source port.   But right now I think that the text is just about messages from relays to relays or servers, in the direction of servers.   Is that correct?   If so, the easiest change would be something like this:

Relay agents implementing this specification may be configured instead to use a source port number other than 67 when relaying messages toward servers, and to receive responses toward clients on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.



_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg