James Carlson wrote:
> Sunay Tripathi writes:
>> James Carlson wrote:
>>>     Warning: you asked for a factory address, but I couldn't get
>>>     one.  I've assigned a random address instead.  If that's not
>>>     ok, then you'll probably want to reconfigure this interface.
>>>
>>> (Or perhaps something more professional-looking than that.)
>> Huh? The guy only wants to deal with factory assigned MAC address
>> and you would still assign a random MAC address and create a VNIC??
>> What does the guy do after that? Run delete-vnic since he doesn't
>> want it in the first place?
> 
> The original context of this was with a "move" operation, where
> failure seems quite strange.
> 
> But, yes, that's exactly what I'd expect to see as a user.  In the
> scenario you cite, I've asked for two things.  I've asked to have a
> VNIC created, and I've asked that it have a factory address.
> 
> Your assertion is that if I can't get one of those two things (the
> factory address), then I get nothing.  You seem to be assuming that my
> request for "factory address" is more important than my request for a
> VNIC, such that my request for the VNIC can be ignored or rejected.
> 
> I'm not so sure that's a useful semantic, and I'm asking whether this
> sort of failure is what users *desire* to see.

Yes, we have about a dozen big customers that do exactly this.

>> I was with you till earlier email that there might be a better way
>> of expressing the requirement that I am only interested in factory
>> assigned mac addresses and *don't* want to deal with random or user
>> created things. But assigning a random MAC address when he asked for
>> factory is almost ignoring the request.
> 
> See above.
> 
> I'm not ignoring the request.  I'm saying:
> 
>       A.  Honor the request if you can.
> 
>       B.  If you can't honor it, then at least create a usable
>           interface.

If that was the intent, the user can use the auto flag and let the
system decide. The fact that he specified factory means he cares
about it.

Your definition of usable doesn't match how this is done today. Users
assert that if I can't match a packet to a physical machine, it
creates more problems. Same as I don't have a IP address so let me
snoop and see what address on the subnet is not in use and use that
instead. One could argue that did create a usable interface.

Understand that randomly created MAC addresses are just that - random.
The probability of duplication in todays data center is a very finite
probability and customers understand that and its an issue for them.

>       C.  For bonus points, you can _always_ issue a warning message
>           for users who somehow think "factory > random."
> 
>>> The problem I have is with the failure mode.  I don't see a purpose.
>> Perhaps if you try to understand the difference between a unique
>> identifier (factory MAC) that is inventoried vs a randomly generated
>> non-unique identifier, it will be clear to you.
> 
> That's still not the question I'm asking.
> 
> I know the difference between random and factory assignment.
> 
> I want to know why forcing failure is preferable to warning (if
> necessary) and driving on, particularly when forcing failure simply
> creates brand new points of annoyance.

Use the *auto* flag and not specify a specific mode if you don't care.

> If you're not interested in covering that in the document, then that's
> fine by me.  Just say you're rejecting my comments.  There's no need
> to assume that I'm ignorant.
> 
>>> I don't understand why they would prefer to see failure.  It doesn't
>>> seem helpful.
>> Failure happen all the time when you run out of resources. We fail a
>> process creation when we are out of memory? We fail a socket open when
>> we run out of descriptors ...
> 
> This is an adminstrative interface, not a dynamic failure mode.
> 
>>> Would users actually be inconvenienced if an interface worked because
>>> it fell back to a random address, where they'd actually have an
>>> advantage if it failed instead?
>> Yes. And yes. When they see a packet on the wire, they need to know
>> which physical machine is sending the packet and what is its location.
> 
> Specifying "factory" doesn't actually tell you what address you will
> necessarily have.  You still must use the status interfaces to tell
> which address you've gotten.

But if you do your inventory properly, when you see a packet on the
wire, you can map it to a physical machine. This is how its done in
real life buy some of our customers.

Sunay

-- 
Sunay Tripathi
Distinguished Engineer
Solaris Core Operating System
Sun MicroSystems Inc.

Solaris Networking:     http://www.opensolaris.org/os/community/networking
Project Crossbow:       http://www.opensolaris.org/os/project/crossbow



Reply via email to