Subject: [dhcwg] clarifying server-id-override

From: Mark Stapp <[email-masked]>
Date: Thu, 23 Mar 2006 12:03:49 -0500

During the wg meeting, I proposed a way to deal with the issues raised 
about the server-id-override draft. I'd like to see what the list thinks.

We spent some time discussing what happens when server-id-override and 
failover or load-balancing are all configured. When server-id-override 
is configured, relays will forward client messages to both failover or 
load-balancing partner servers. The client messages will all contain 
giaddr, and the servers will not be able to distinguish between client 
unicast RENEWs and client REBINDs. Both servers will have to either 
respond, causing extra server work, or will have to do some amount of 
work to determine whether they can safely ignore the client message.

At least one person suggested that that extra work would be so onerous 
that we had to develop a mechanism to allow the relay to indicate 
whether the clients' messages had been unicast. Further, 
server-id-override could proceed forward only if it included a MUST, a 
normative reference, to that mechanism.

I'm not as convinced that the issues require such a dramatic solution 
that it's necessary to block server-id-override while waiting for the 
unicast indicator to reach the same point in the process. I'd like to 
propose an alternative. In my view, server-id-override, failover, and 
load-balancing are all optional. Turning various combinations of them on 
is not mandatory.

1. I'd like to clarify the issues that can arise in the 
server-id-override draft, so that someone who wants to use these things 
in combination will be made aware of the implications.

2. I'd like to add an INFORMATIVE reference to the work-in-progress 
draft containing the unicast indicator, as a way to mitigate the issues 
in (1). That would allow server-id-override to move forward, but 
establishes a connection between the two mechanisms.

Comments?

-- Mark

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Mar 2006 20:35:21 +0000

> normative reference, to that mechanism.

I think I disagree with this summarization, but I suspect that is due
either to the way I read it, or the expedience utilized in writing it.

Substantively, I think the LBA/failover and unicast/broadcast issues
are two separate ones (and I don't think a unicast/broadcast flag is
going to fix it).

But it doesn't matter, because I agree with your conclusion anyway.

> in combination will be made aware of the implications.

Right.  "Server-override + LBA is considered harmful."

> establishes a connection between the two mechanisms.

Right.  "I actually can't think of a snarky summary."  This would be
to address the unicast/broadcast issue, whereas the above addresses
the LBA issue.

> Comments?

I agree.

The only reservation being the INFORMATIVE reference should be made to
a draft that has been accepted as a WG item (to my mind, that acceptance
indicates the WG is committed to following through - and that we all
agree roughly on the way in which it should go forward (but we reserve
the right to be wrong)).

Discussion (expanding on my opinion);  there is actually more than one
reason for using server-override, and in precisely one of those the
situations we're describing are less harmful than the current reality
it was designed to correct (not being able to communicate with a client
at all).

I think it's perfectly reasonable to let the current problem in the
currently defined environment be fixed, and let future work apply this
fix to other environments (with the patches necessary).

Of course it also means that the document needs to define that
environment, and limit the scope of its work to it (so, I repeat my
opinion: that I think the IESG comments were on-target in this vein).

-- 
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