Subject: [dhcwg] *REMINDER*: dhc WG last call on draft-ietf-dhc-vpn-option-09.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Dec 2008 05:46:50 -0500

REMINDER: This WG last call will end on Dec 19.  We have only received  
one review of the document, and need several more reviews before the  
document can be advanced to the IESG.

This message announces a WG last call on "Virtual Subnet Selection
Options for DHCPv4 and DHCPv6" <draft-ietf-dhc-vpn-option-09.txt>.
The last call will conclude at 1700PDT on December 19, 2008.  This
document is intended for publication as a Draft Standard.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.  Note that there was only one response to the previous WG
last call for this document, which is at
http://trac.tools.ietf.org/wg/dhc/trac/ticket/12.  That response will
be considered as part of this new WG last call.

draft-ietf-dhc-vpn-option-09.txt defines a Virtual Subnet Selection
(VSS) option for DHCPv4 and DHCPv6, and a DHCPv4
relay-agent-information sub-option.  These are intended for use by
DHCP clients, relay agents, and proxy clients in situations where VSS
information needs to be passed to the DHCP server for proper address
or prefix allocation to take place.  For the DHCPv4 option and
relay-agent-information sub-option, this memo documents existing usage
as per RFC 3942 [RFC3942].  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-09.txt

- John Brzozowski, Ralph Droms
  dhc WG chairs

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Dec 2008 00:48:03 -0500

I fully support this document moving forward.

There are two minor issues that we might want to consider:

1. Should there be any text suggesting what the server should send back?
Perhaps we should recommend that if the server sends back the VPN
(sub)option, it SHOULD return the VPN information in the same format it
was provided by the client/relay (ie, name vs VRF) if possible. And, if
it must send the option when the client/relay did not provide it, it
should prefer to send back the VRF (if available)? 

Perhaps in 7.  Server Behavior, we could add:

    If a server uses a different VPN than what it received, it SHOULD
    send back the VPN information using the same type as the received
    type. It MAY send back a different type if it is not possible to
    use the same type (such as the RFC2685 VPN-ID if no ASCII VPN
    identifier exists).

2. For v6 (could also be an issue for v4), what happens if the
client/relay provides this option in the ORO (PRL)? And, should the
client/relay, if it wants it sent back, include it in the ORO (PRL)?
Perhaps we consider this a "core" protocol option (similar to the IA_NA,
IA_PD, IA_TA) where the option is not required to be in the ORO (PRL) as
the semantics require the server to send it back if received.

Again, both of these are minor and I think the document is fine "as is".

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 Dec 2008 11:51:30 -0800

> the semantics require the server to send it back if received.

ERO?

I'm not sure if there are existing implementations we're working with
either.  This was an RFC 3942 action that intended standards track
instead of informational...

For DHCPv6 relay agents we have a curious situation as well.  The
relay agent's request option is the ERO; but this implies only echoing
the relay's prior contents.  Should the relay agent provide an ORO if
it expects a VPN assignment, and ERO if it expects to assign the VPN?

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Dec 2008 23:55:26 -0500

I think ORO, if anything, is appropriate. ERO requests the option to be
echoed back, which is different, as the VPN can change. I don't think
the complexity of allow either ORO or ERO (and the subtle meaning
difference) is worth it.

Also, we have both the client and relay agent which could supply the
option; ERO is only for relays, as clients are stateful and thus there's
no reason they'd need something they sent in echoed.

---

>This was an RFC 3942 action that intended standards track

Yes, the DHCPv4 option was that -- and there was no requirement for PRL.

The DHCPv6 option is a bit different as it is new. And, we've been
trying to be much better about using the ORO than we were the PRL.

I don't have strong feelings either way. I lean towards considering this
option a "core" protocol option and thus does not require ORO - if a
server supports it, it must do processing to do so and hence there's
really little need to include it in the ORO.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Wednesday, December 17, 2008 2:52 PM
To: DHC WG
Subject: Re: [dhcwg] *REMINDER*: dhc WG last callon
draft-ietf-dhc-vpn-option-09.txt

ERO?

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 18 Dec 2008 09:52:33 -0800

> no reason they'd need something they sent in echoed.

Yes; but the draft describes several different scenarios, some of
which the relay would expect its transmitted value returned, and in
others would expect an assignment by the server.

> really little need to include it in the ORO.

I don't think processing is required in all of the scenarios the draft
supposes.

So I'd lean towards putting the option on ORO; older servers with no
support can still mimic sufficient support with manually or scripted
values, but they won't send the value unless it's on ORO.

This also simplifies DHCPv6 packet creation routines by treating more
options consistently the same.