Subject: RE: [dhcwg] dhc wg last call on "DHCP RelayAgentAssignmentNotification Option"

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 13 May 2006 10:03:26 -0400

David:

> So I think the question is: Does the Release only absolve the client
> address binding, and not the prefix delegation binding?

The Release is supposed to "clear out" everything. As the client has
indicated that it is no longer using this information, it should be
removed and available to be potentially used by another client (though
how soon thereafter is a matter of policy and allocation algorithms on
the server).

> At IETF 64 (I think), I thought you told me the whole question about
> how routing injection/withdrawal would work would be completely out
> of scope for this work.

I think what I was talking about was the multiple relay/router issue? As
the draft proposes including information in the Relay-Reply it will only
be seen by one of the routers and the issue of communicating this to
multiple redundant routers is what is out of scope for DHCP. Redundant
routers already have to deal with these kinds of issue?

The main purpose of this option is to provide this information to a
relay/router. Section 1. Introduction has:

   For example, a network administrator uses the DHCP Relay Agent
   Assignment Notification option to inform a relay agent of a prefix
   that has been delegated through DHCP PD to a DHCP client.  The relay
   agent notifies the network element on which the it is implemented of
   the delegation information so the network element can add routing
   information about the delegated prefix into the appropriate routing
   protocols.

What is in scope is the DHCP Relay Agent Assignment Notification. What
is out of scope is how the network element handles any routing injection
and/or populating ACLs (section 3).

- Bernie

> -----Original Message-----
> From: David W. Hankins [mailto:[email-masked]] 
> Sent: Wednesday, May 10, 2006 12:13 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc wg last call on "DHCP 
> RelayAgentAssignmentNotification Option"
> 
> On Wed, May 10, 2006 at 08:47:01AM -0400, Bernie Volz (volz) wrote:
> > - For Renew/Reply, Relay B will start injecting the routes for the
> > delegated Prefixes. Relay A will continue to inject them 
> until the valid
> > lifetime expires. Thus, for a time, both relays will advertise the
> > prefix; eventually only Relay B does.
> 
> Sounds fine.
> 
> > - For Release/Reply, Relay B won't have a record of the 
> delegated prefix
> > and may thus take no action. Relay A will continue to 
> inject the routes
> > until the valid lifetime expires.
> 
> Or relay B might have a record due to the first case you 
> cited and will
> withdraw its own route advertisement, but can do nothing to 
> cause relay
> A to withdraw theirs.  Which is still an identical problem.
> 
> Then, this is only a problem if the prefix is reallocated to another
> client address (which may or may not be the same client) before the
> lifetime expires.
> 
> So I think the question is: Does the Release only absolve the client
> address binding, and not the prefix delegation binding?
> 
> Dynamic DNS, for example, is absolved on release.  So it would seem
> odd for the prefix delegation to not also be absolved.
> 
> Intuitively, however, Dynamic DNS is commonly only kept, in terms of
> server-kept state, on any records indicating the assignment of the
> lease to the client.  Delegated prefixes, on the other hand, would
> have to come out of some common pool, and when freed would have to
> return there.
> 
> > If you don't use this technique, what other means will be 
> used to inject
> > these routes into the routing infrastructure? In some 
> cases, the client
> > may be allowed to do it. But, in many that won't be 
> possible as there
> > isn't any strong trust relationship between the client and relay.
> 
> I'm not sure where that came from.
> 
> I'm not really following your draft very closely, I just tried to
> ask a question about how the relay might get out of the loop.  I had
> no idea at the time it had anything to do with route advertisements,
> I was just asking if you'd considered the case of multiple relays.
> 
> At IETF 64 (I think), I thought you told me the whole question about
> how routing injection/withdrawal would work would be completely out
> of scope for this work.
> 
> If it's out of scope, so should this discussion be?  I admit I'm a
> fairly confused about why we're even talking about this.
> 
> I thought you explicitly weren't providing any guidance for how
> routing might be injected or withdrawn.
> 
> So why does it even matter if the transport is or is not reliable?
> 
> If all of this is decidedly out-of-scope, then none of it matters.
> 
> If it is in scope, then I guess we need to talk about it.
> 
> > If we try to solve the problem completely, we'd need to get 
> into routing
> > protocols and much more. And, this isn't typical of likely 
> 95% of the
> > deployments -- so why build something that is so 
> complicated, crosses
> > multiple IETF WGs, has very limited scope, and takes many years to
> > develop. 
> 
> I'm not sure what you're arguing since I haven't suggested making any
> changes.
> 
> So I don't know what it is you think is 5% of deployments, has limited
> scope, or takes too long to develop.
> 
> I think you're confusing my query about alternative relay agents with
> a question I asked...it seems years ago now.
> 
> > Let's solve the most common problem first and if there's a 
> need, we can
> > look at the edge cases -
> 
> Although I admit my background is not in IPv6 broadband network
> deployment, and I rather wonder who can say theirs is, my experience
> in IPv4 tells me that the common problem is the one where fault
> tolerant relays live.
> 
> That is, this will not fly if the architecture relies upon a single
> point of failure to work.
> 
> Maybe some other operators can tell us if they prefer to use one or
> two DHCPv6 relays in their broadband-access networks.
> 
> So far, all my DHCP(v4) customers (and my own preferences from
> networks past) are telling me: 'two'.
> 
> So I think redundant relays has to be a given in the network
> architecture this protocol would be used on.
> 
> > - or leave that for vendors to add value.
> 
> I am of the opinion that it should not take vendor value-add to make
> an IETF protocol operate efficiently and normally in commonly adopted
> network architecture.
> 
> -- 
> 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: "David W. Hankins" <[email-masked]>
Date: Mon, 15 May 2006 08:53:26 -0700

> how soon thereafter is a matter of policy and allocation algorithms on

Then Thomas is right: the reliability (or lack thereof) of the message
passing channel is a problem you need to solve reliably, or else this
doesn't work.

> I think what I was talking about was the multiple relay/router issue?

You honestly believe only 5% of DHCPv6 deployments with relay agents
will use more than one relay on each network segment?

That's the largest reason I thought you jumped topics.

I'm really interested to know why you think 95% of networks want
single points of failure in their DHCPv6 relay agent infrastructure.

This point of view is completely disjoint from my own.

> As
> multiple redundant routers is what is out of scope for DHCP.

Sounds like yet another thing to gum up or break to me, but it also
doesn't sound like my problem.

> Redundant

Redundant DHCPv6 relays you mean?

Either way: not that I'm aware of.

Distributing routing information among multiple routers, sure, that's
the whole point of routing protocols.

Distributing the need to inject that routing information?  Not that I
know of.

Distributing held-state between relay agents?  Well, as relay agents
are inherently stateless, that hasn't really been a need so far...

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