Subject: [dhcwg] draft-kinnear-dhc-relay-agent-flags-00.txt

From: Kim Kinnear <[email-masked]>
Date: Thu, 08 Jun 2006 15:53:01 -0400

Folks,

At the Dallas IETF, we discussed having a DHCPv4 relay agent
sub-option for flags, where the first flags was to indicate
whether the DHCP request forwarded from a Relay Agent was
received by the Relay Agent as a unicast or a broadcast.

The initial impetus for this sub-option was David Hankins'
realization that the server-id-override draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-03.txt

was obscuring the difference between a DHCPv4 client's broadcast
and unicast transmission of a DHCPREQUEST/RENEW, thus making the
DHCPBROADCAST/RENEW look like a DHCPREQUEST/REBINDING.  This made
it difficult or impossible to adhere directly to RFC2131.  It
also made load balancing effectively useless if the
server-id-override capability was exercised.

We have put together a draft which specifies a flags sub-option
for the relay agent info option, and includes a flag for unicast
or broadcast reception by the Relay Agent:

http://www.ietf.org/internet-drafts/draft-kinnear-dhc-relay-agent-flags-00.txt

There has been some off-list discussion about whether to push
this forward as a separate draft or whether to include this new
sub-option inside of the existing server-id-override draft.

Several people initially felt that combining the drafts was the
most expeditious approach, and I don't deny that.  Certainly if
we need the server-id-override draft to reference (in pretty much
any way, even using a SHOULD) the relay-agent-flags draft, they
should probably be together.

Alternatively, the relay-agent-flags byte is useful outside of
the scope of the server-id-override option, and may well have
more general applicability -- which makes combining the drafts a
bit awkward, since the relay-agent-flags could easily get lost in
the other draft.

In any case, whatever we decide to do here (and it doesn't make
*that* much difference), we thought that reviewing the ideas and
words might be easier using a separate draft.  Once we get
general agreement that we have the sub-option we want, we can
integrate it into the server-id-override draft or continue to
push it as a separate draft.

If we can get feedback soon on this draft, then we can fix it in
time for the submission deadline for the next IETF and integrate
it if that is the sense of the list.

Enjoy -- Kim

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Jun 2006 14:58:24 -0700

> http://www.ietf.org/internet-drafts/draft-kinnear-dhc-relay-agent-flags-00.txt

This is perfect.

In the event an option content longer than 1 byte is received by the
server, do we need stronger language there to make sure servers evaluate
the first octet?  It's pretty plain to me since it describes itself as
an extensible flags field, but I'm also going into this knowing that's
the goal.

I also think the flags field gives us a general hammer to use when (if?)
someone undertakes the work for Ted-Complete (sorry Ted) failover support,
wherein the servers no longer receive copies and the relay agent provides
the load balancing...the agent advertising the capability can be carried
this way for example without additional option overhead.

I think I see (hazily) how failover works in this interim world order
with just this flag.  I will endeavour to see this more crisply before
the submission deadline.

> push it as a separate draft.

I said it in person in Dallas, I'll encode it here for posterity as
well: I only ask that the WG accept Kim's draft as a WG item.  That
solves my objection.  In my opinion, with that done, the other draft
may proceed in parallel on the basis that despite even my own concerns
for "protocol purity".  It solves the more serious problem where
the servers and clients can't directly unicast if only people are
a little careful about how they deploy the technology.

> it if that is the sense of the list.

Given.

> Enjoy -- Kim

Thank you for your effort on this, Kim, I appreciate it.

-- 
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://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 08 Jun 2006 18:16:35 -0400

>an extensible flags field, but I'm also going into this knowing that's

        Good thought.  I assume that you mean that if it is more
        than one byte, that only the first byte has any
        significance.

        We'll add this.

>well: I only ask that the WG accept Kim's draft as a WG item. 

        I kind of thought we did in Dallas, but we could do that
        over the list to be sure.

        Ralph, Stig -- can we accept this draft as a working
        group work item over the list?  How do we do that?

        Thanks all -- Kim

> That

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Jun 2006 15:22:55 -0700

>         than one byte, that only the first byte has any

Yes, precisely.