Subject: [rbridge] Optional configuration of RBridge nickname

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 01 May 2007 21:26:16 -0700

Someone suggested that it would be useful to allow configuration of 
nicknames, so
that nicknames can be more stable, and there would be no worry of an 
RBridge coming
up and usurping a nickname from someone else. I'd like:
a) for it to remain possible to be zero configuration (as in, not 
necessary to configure
a nickname
b) allow a mixture of configured and unconfigured nicknames
c) work even with misconfiguration (configuring two RBridges with the 
same nickname)
d) never allow an unconfigured nickname to accidentally usurp a nickname 
from
a ocnfigured RBridge

So I'm proposing the following:

a) allow configuration of a nickname value
b) have a "priority" value for owning a nickname
that can also be configured, which I'd propose would be an 8-bit byte,
where only the bottom 7 bits can be configured
c) the 8th bit of the priority byte (the most significant bit) indicates 
whether
the nickname was configured or not
d) the default is priority=0 for RBridges that have not been configured with
a nickname value, and priority=128 (top bit 1, rest 0) for an RBridge that
has been configured with a nickname
e) other values of nickname priority might be useful. For instance, an 
RBridge
implementation might increment the nickname value after it's held the 
nickname
for some amount of time (say 10 minutes). Or someone might want to configure
some RBridges to have a more stable nickname (by giving them higher 
priority).
f) Basically, the (nickname priority | system ID) is like the DR 
priority in IS-IS,
where the DR election is based on (priority | system ID)

Anyone object to this?

Radia

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 05:31:02 -0500

Radia,

	I would object strenuously to the use of a priority
value in resolving the "ownership" of a nickname.

	The over-riding priority has to be determined in a 
way that ensures the existing network continues to work 
if a new device is inserted (i.e. - it would be best if
any device were going to fail, it should be the one that
has just been added).

	Adding "priority" would allow any device to assert
a high priority ownership of any nickname currently in 
use, which would then make it trivially easy to stage a 
network disabling attack.

	Having it be so easy to attack the network, would
necessitate mandatory defenses, almost certainly meaning
that configuration would be required - possibly excepting
the option of having the very highest priority value be 
the default assumed when no configuration is done at any
RBridge.

	In either case (configuration absolutely required,
or default highest priority with no configuration) would
defeat your purpose.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Wednesday, May 02, 2007 12:26 AM
> To: rbridge at postel.org
> Subject: [rbridge] Optional configuration of RBridge nickname
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 09:06:25 -0700

Eric,

There is a strong requirement in Enterprise to disable any form of
autoconfiguration. I requested Radia to support a way to manually
configure Nicknames. I am not asking this being the default, but it must
be supported.

The solution that Radia has put together is satisfactory for me. If I
want to manually configure a nickname I will do it and set the highest
priority. 

Lacking a secure authentication scheme the network can be attacked by
any PC in a much easier way.

--Silvano

> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 02, 2007 3:31 AM
> To: Radia Perlman; rbridge at postel.org
> Subject: Re: [rbridge] Optional configuration of RBridge nickname
> 
> Radia,
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 12:17:00 -0500

Silvano,

	Perhaps I am reading your requirement incorrectly,
but it sounds to me that it could be as easily addressed
by requiring that implementations support a way to shut
nickname-negotiation off.

	Consider simply having a pair of management objects
- one to disable auto-nickname negotiation, and another
(which must be assigned a value if the first is disabled)
that contains the configured nickname.

	In my opinion, that would be a much more acceptable
approach - especially in comparison with using priority
as a mechanism for varying the outcome of auto-negotiation
without actually turning it off.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Wednesday, May 02, 2007 12:06 PM
> To: Eric Gray (LO/EUS); Radia Perlman; rbridge at postel.org
> Subject: RE: [rbridge] Optional configuration of RBridge nickname
> Importance: High
> 
> 
> Eric,
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 16:50:12 -0700

Eric, 

I think you are reading it correctly and having an implementation to
support a way to shut nickname-negotiation off is what we need.

The problem is that after I have manually configured a nickname on an
RBridge I need to be sure that no other RBridge in the network selects
it.

I also need to take into account that due to a mistake I can manually
config the same nickname on two RBridges.

One thing after the other we ended up with Radia proposal, but if you
have a better one, we are happy to listen.

Cheers

-- Silvano

> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> Sent: Wednesday, May 02, 2007 10:17 AM
> To: Silvano Gai; Radia Perlman
> Cc: rbridge at postel.org
[mailto:rbridge-bounces at postel.org]
> > > > c) work even with misconfiguration (configuring two RBridges
with
> > the
> > > > implementation might increment the nickname value after it's
held
> > the

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 08:24:33 -0500

Silvano,

	I believe that it is easily arguable that having a network
in which some devices are configured not to negotiate, while the
rest are not so configured (and default to negotiation) MUST be 
considered a configuration error.  In many ways, this SHOULD be 
considered the same sort of error as might occur if two devices 
were configured with the same value.

	One mitigating factor for this particular configuration 
error is that one very likely way in which it would occur - i.e.
- as a result of powering up an unconfigured device, is a "safe"
operation if the (default) negotiation scheme favors the "status
quo" assignment (as I believe we all have agreed it MUST).

	Another likely pair of scenarios are as follows:

A) one in which a new device is added to an existing deployment 
   where the existing devices are using negotiation and the new 
   device is configured with a value that just happens to be the
   same as one that an existing device has negotiated 

   - is clearly analogous to -

B) one in which a new device is added to an existing deployment
   where the existing devices are configured with values (and
   not using negotiation) and the new device is configured with
   the same value as one that has previously been configured 
   for an existing device.

	I am reasonably confident that these SHOULD be viewed as
simple configuration errors in both cases.

	I suggest that it follows from this line of reasoning that
it MUST always be possible to create a conflict situation as a 
result of configuration errors.  Hence it should also follow that
a simpler approach is more desirable than a more complicated one.

	As the saying goes, let's apply the KISS principle and do
what makes the most direct sense in terms of the goal we want to
achieve.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, May 02, 2007 7:50 PM
> To: Eric Gray (LO/EUS); Radia Perlman
> > > The solution that Radia has put together is satisfactory 
> for me. If
> I
> > > > > that can also be configured, which I'd propose would 
> be an 8-bit
> > > byte,

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 3 May 2007 07:08:32 -0700

Eric,

I am all in favor of KISS and I agree on your scenarios, but I am not
able to come up with a solution simpler than the one Radia proposed.

In Fibre Channel, FC-SW allowed only auto-configuration. The FCIDs
(nicknames) were selected in a way extremely similar to what TRILL
proposes. We had a strong push back from customers and we had to modify
the standard to allow manual configuration.

I just want to design it right from day 1 in TRILL

-- Silvano

> Sent: Thursday, May 03, 2007 6:25 AM
> > > > Lacking a secure authentication scheme the network can be
attacked
> > by
> > > > > > a) for it to remain possible to be zero configuration (as
in,
> > not
> > > > > > d) never allow an unconfigured nickname to accidentally
usurp
> > > > > > a nickname value, and priority=128 (top bit 1, rest 0) for
an
> > > > > > RBridge that