RE: [dhcwg] Interface

> Perhaps I'm confused, but don't we have an issue that we should attempt to
> resolve when a client has multiple interfaces to the same link?
> 
> A client may not know this.

I think that the client either needs to know this or be very robust.
For example, today a client might be confused to see the same subnet prefix
appear on one interface. But that would be the norm when a client has
multiple interfaces on the same link.

> I believe IAs should be client specific, not interface specific.

What problem are you trying to solve with this?

When the client has multiple interfaces on different links I assume you want
different IAs for those.

Client that are aware that they have multiple interfaces on the same link
might still want different IAs for those interfaces (so that they can get
some inbound load spreading across the interfaces for instance).

   Erik

> But, that
> still doesn't solve the problem because hows does the server know that there
> are two interfaces on that client? (Instead of treating all IAs to belong to
> the first interface.) This could lead to significant problems if we allow a
> server to tell a client all of the IAs for that client on that link (in an
> Advertise, for example).
> 
> - Bernie
> 
> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, September 20, 2001 1:12 PM
> To: Ted Lemon
> Cc: Erik Nordmark; Bernie Volz (EUD); 'Guja, ArturX'; dhcwg@ietf.org
> Subject: Re: [dhcwg] Interface 
> 
> 
> > 
> > > But that's beside the point - which is to not overconstrain the spec 
> > > with MUSTs that aren't quite true.
> > 
> > The point is to come up with a working, implementable protocol
> > definition, that does not only work if you happen to be running
> > 802.3ad in a certain obscure implementation.
> 
> Ted,
> 
> the tone of your statement reads like an attack on a particular unnamed 
> implementation.  I certainly did not describe an existing implementation -
> in fact I have no idea whether there exists an IEEE 802.3ad that does what
> I described. (And the whole mention about implementation was in response to
> a question whether there was an automatic way for hosts to determine that
> multiple interfaces are connected to the same link.) Sigh :-(
> 
> What I did point out is that the IPv6 architecture allows multiple interfaces
> connected to the same link. That is the real issue.
> 
> > Most implementors will not run into the corner case you've just
> > described, but those same implementors have a pretty good chance of
> > producing a non-interoperable client implementation if that MUST isn't
> > there.  In the corner case you've described, unless I am very much
> > mistaken, the MUST will _not_ cause a problem.  So the MUST should
> > stay.
> 
> I don't think MUSTs are intended to prescribe rules for a subset of
> the implementations - their original use was to describe (often subtle)
> things that implementors had overlooked in the past that caused rather bad
> things to the network (such a broadcast storms).
> Today MUSTs are used to make firm statements for behavior
> that applies to all implementations.
> 
> So you seem to be describing a case where a SHOULD applies. RFC 2119:
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> Alternatively text along the lines of this makes sense
> 	"... MUST (unless where the client has multiple interfaces connected to
> 	the same link [SCOPING-ARCH] in which case the ... MUST be for one
> 	of the interfaces connected to the same link) ..."
> 
>   Erik

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg