Subject: Re: [dhcwg] clarifying server-id-override

From: Stig Venaas <[email-masked]>
Date: Mon, 24 Apr 2006 13:12:03 +0200

David W. Hankins wrote:
> On Thu, Mar 23, 2006 at 12:03:49PM -0500, Mark Stapp wrote:
> 
>>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 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.
> 
> 
>>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.
> 
> 
> Right.  "Server-override + LBA is considered harmful."
> 
> 
>>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.

Having read IESG's statement on normative and informative references 
(posted to ietf-announce on April 19th), I think it's difficult to have 
an informative reference to such an indicator, even if it is optional.

 From the statement:

    in the new RFC to work. An informative reference is not normative;
    rather, it only provides additional information. For example, an
    informative reference might provide background or historical
    information. Informative references are not required to implement the
    technology in the RFC.

    Note 1: Even references that are relevant only for optional features
    must be classified as normative if they meet the above conditions for
    normative references.

If we're talking about a single bit as indicator for unicast/multicast, 
then it appears to me that we could easily add this to the draft now, 
and do new last calls ASAP. I think the last calls could all be done in 
just 2-3 months time, so not that much of a delay really. Figuring out 
how to possibly informatively reference another draft from current 
server-override draft may also take some time. I also feel a bit better 
about having this in one single document where implementing this 
indicator could at least be a SHOULD.

So my suggestion is to just quickly add this indicator to the draft and 
do new last calls. At least if we agree that such an indicator is the 
way to go.

Stig

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

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