Virtual Subnet Selection Options for DHCPv4 and DHCPv6
draft-ietf-dhc-vpn-option-15

I still think that using the terms "relay-agent-information sub-option" and "relay sub-option" interchangeably adds confusion

5.  Relay Agent Behavior

   Anytime a relay agent places a VSS option or sub-option in a DHCP
   request, it MUST send it only to a DHCP server which supports the VSS
   option or sub-option.

Does this need to be a MUST? This seems like configuration/policy.


7.1.  Returning the DHCPv4 or DHCPv6 Option

   The appearance of the DHCPv6 VSS option in the OPTION_ORO [RFC3315]
   or the OPTION_ERO [RFC4994] should not change the processing or

"SHOULD NOT"?

   decision to return (or not to return) the VSS option as specified in
   this document.


9.  IANA Considerations

   While the type byte defined in Section 3.4 defines a number space
   that could be managed by IANA, expansion of this number space is not
   anticipated and so creation of a registry of these numbers is not
   required by this document.  In the event that additional values for
   the type byte are defined in subsequent documents, IANA should at
   that time create a registry for these type bytes.  New values for the
   type byte may only be defined by IETF Consensus, as described in
   [RFC5226].  Basically, this means that they are defined by RFCs
   approved by the IESG.

This is an interesting way of saying that new IANA registry is not needed, but then putting requirements on future documents if this registry established in the future. Is this text needed?

1. The Terminology section defines upstream and downstream using terms that have not been defined.
It is unclear to me whether access concentrator and subscriber are similar to server and client.

2. In section 3.4, might it be better to declare 2-254 as reserved rather than invalid?
The text says "invalid as of this memo".
Should there be a mechanism to support enterprise-specific VSS?

3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true? Is there any potential for conflict, such as in forwarding loops, if the two addresses spaces are handled by the same device?

4. I think section 4 would benefit from sub-sections to separate the scenarios, and all the "in this scenario" phrases could be eliminated.
Diagrams of the scenarios would be helpful.

5. Will legacy DHCP entities ignore the VSS option by default? or will the presence of the option somehow impact entity behaviors (e.g., by dropping packets)?

6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option? That isn't discussed.

7. Section 5 says
   "Anytime a relay agent places a VSS option or sub-option in a DHCP
   request, it MUST send it only to a DHCP server which supports the VSS
   option or sub-option." How does it know? is there an option discovery mechanism?

8. In section 5, if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses?

9. In section 5,  "If an IP address that is on the requested VPN is not required, then the relay agent is free to accept the IP address that is not on the VPN that was requested." Then why request it? Under what conditions would it not be required? how does the relay know whether it is or is not required?

10. In section 5, it says "There are only two pieces of information which can be determined ..." but the speciied behaviors could also result from mis-configuration, right? And the relay cannot tell whether it is a deliberate behavior or a mis-configuration.

11. section 5:   " Thus, if a DHCPv4 relay agent has a requirement to
determine if the address allocated by a DHCPv4 server is on a particular VPN, it must use some other approach than the appearance of the VSS sub-option inthe reply packet to make this determination." What other approach works?

12. section 5: "   Note that in some environments a relay agent may
choose to always place a VSS option or sub-option into packets and messages that it forwards in order to forestall any attempt by a downstream relay agent or client to specify VSS information.  In this case, a type field of 255 is used to denote the global, default VPN.  When the type field of 255 is used, there MUST NOT be any additional VSS
Information in the VSS option."  This section does not say that the relay must check to make sure there is no existing VSS option. Section 5 talks about relays inserting VSS options, but does not specify that the relay must check that no VSS=255 is present in the message already.
But section 7.3 talks about resolving conflicting VSS options. I am not sure the potential conflicts abd resolutions are covered adequately.

13. section 5.1 what does "if the relay agent is unable to honor the server requirement" mean? This could be made less ambiguous.

14. section 5.1 "   The DHCP server MUST NOT place VSS information in
an outgoing packet if the relay agent or DHCP client is unprepared to properly interpret the VSS information." This seems ambiguous. How will the server know if the other entities can properly interpret the VSS information?

s/send in/insert/

15. Section 4 says "The DHCP client, in this scenario, does not know the VPN on which it resides. Section 6 says "A DHCPv4 or DHCPv6 client will employ the VSS option to communicate VSS information to their respective servers.  This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN."
These statements seem to conflict regarding the client's knowledge.

16. section 6: "   Clients should be aware that some DHCP servers will
return a VSS option with different values than that which was sent in.  In addition, a client may receive a response from a DHCP server with a VSS option when none was sent in by the Client."

So should subsequent messages from the client use the original VSS information or the server-returned or relay-returned VSS info? 

Can a return message contain multiple VSS options? If I read the document correctly, multiple relays can add their own VSS options, and a server typically copies all the options. If a client is expected to include the VSS option information in subsequent messages, does it include multiple VSS options? The second paragraph of 6 says that is not allowed.

17. The terminology issue concerns the use of the word "global"
for non-VPN addresses. According to the use of this term, also a "private" IP address, such as 10.X.X.X, is called "global".
Is it appropriate calling it so even if this address is usually called "private" and is not globally routable?

The draft says in line 6 of the second paragraph of section 4:
" ... the IP address space is in the global or default VPN used throughout the Internet". Are private IP addresses used throughout the Internet? Maybe ...
 
For me this terminology choice is confusing. I would rather rename it or at least add an entry to the terminology section that "global"
does not cover public IP addresses only but includes also private ones.

----

18. In lines 3-5 of the 3rd paragraph of section 4 the draft says:
"There is no conflict in this allocation, since the clients have essentially different IP addresses. Shouldn't it be different "IP address spaces" instead of "IP addresses"? Earlier in this paragraph you say the the IP addresses may be the same. Only the address spaces are different.

----

19. page 4, 4th paragraph:
"It is important to ensure that each entity in this scenario ..."
As far as I understand this applies only to the DHCP relay and server and not to the client. The client would be an antity in the scenario to which it is not important to ensure this.
If I'm correct, please change the text accordingly.

----

20. section 6, last paragraph:
Here "should" and "should not" are used. Shouldn't they get replaced by "SHOULD" and "SCHOULD NOT"?

21. section 1, lines 6-7:
"The configured rates are below the rate of the link ..."
would "the rate of the link" be "the maximum rate of the link"?

This is a fine document. There is one issue I'd like to mention, namely, the term "NVT ASCII VPN identifier" is underspecified. This term might refer to something like "an identifier containing characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text or initiate a conversation about appropriate changes. Also, please expand "NVT" on first use.

  The Gen-ART Review by Roni Even on 1-Jan-2012 includes some editorial
  suggestions.  Please consider them.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07005.html

I modified this discuss to add some more nits I found:

I'm curious about the answer to David's discuss.

Nits:

s3.2: r/see Section 35./see Section 3.5.

s3.3: r/This sub-option only only/This sub-option only

s5: r/DHCPvr4/DHCPv4

- NVT ASCII could do with a reference.

- Last sentence of section 5 is odd. (just before start of 5.1)

I support Jari's discuss with respect to differentiating between relay and client behavior.

To my reading, the only scenarios that are known to be useful involve VSS-aware relays
and clients that are not VSS-aware.  However, the document indicates clients can make use
of this option.