Subject: [rbridge] Question about reserved nicknames

From: Radia Perlman <[email-masked]>
Date: Thu, 14 May 2009 22:28:04 -0700

I notice there were some nicknames set aside as "reserved". What are 
RBridges
supposed to do about reserved nicknames? Merely not request them, or check
data packets, and drop
packets with the TRILL header having either ingress or egress nickname
field set as one of the reserved values?

If the latter, what do people envision using reserved nicknames for in 
the future?
Would such a use be compatible with existing RBridges discarding frames
that use reserved nicknames?

Radia
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 15 May 2009 10:02:59 -0400

Hi Radia,

The behavior you describe is what was intended for the reserved
nicknames with the one minor exception that there is currently no
requirement to examine the ingress nickname on receipt of a known
unicast TRILL data frame. So an RBridge might not discard such a frame
if the ingress nickname was a reserved value. Perhaps that should be a
requirement.

This was discussed on the list. Its really not much different from the
extra reserved multicast bridging MAC addresses, which are dropped by
any bridge which doesn't understand them, or the extra reserved
multicast TRILL MAC addresses, which are dropped by and RBridge which
doesn't understand them. Maybe the reserved nicknames will be helpful
in handling control messages on links that don't have outside MAC
addresses or somehow helpful in implementing "provider RBridges"
if/when we want to do something like that. In any case, it is quite
cheap to reserve them and, if we ever want the behavior of dropping
such TRILL frames, that requirement has to be imposed from the
beginning.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: James Carlson <[email-masked]>
Date: Fri, 15 May 2009 10:38:16 -0400

> if the ingress nickname was a reserved value. Perhaps that should be a

The behavior I'd suggest would be to ignore the ingress nickname on
forwarding, and drop invalid ones only at egress.

The rationale is that it'll be harder to deploy a future nickname-
based protocol that requires forwarding if forwarding is disabled now.
If forwarding is not desired in some future protocol, then the hop
limit can always be used to prevent it.

For the egress, of course, life is different: you must learn the
ingress for the source based on the ingress nickname, and that means
it can't be an "illegal" one.  Some future protocol can (again) amend
that behavior as needed.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Fri, 15 May 2009 12:02:16 -0700

Ah. I'd been doing some last minute rereading of the spec and couldn't 
find what it said to
do with reserved nicknames, but yes...the spec does explicitly says to 
drop if the egress nickname is unknown
or reserved. So I'm glad that that is the behavior everyone wants.

Radia

---

From: James Carlson <[email-masked]>
Date: Fri, 15 May 2009 17:03:10 -0400

> or reserved. So I'm glad that that is the behavior everyone wants.

Right; but I don't think it says what to do with ingress nicknames.  I
think the right answer is:

  - MUST NOT send with a reserved nickname as ingress
  - MUST ignore ingress nickname when forwarding
  - MUST discard packets with reserved ingress nickname at egress node

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 15 May 2009 19:56:41 -0400

>  - MUST discard packets with reserved ingress nickname at egress node

That's fine for known unicast. But for multi-destination frames, if
the ingress is a reserved value, you can't do the RFP check, so it
would seem better to drop those.

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Mon, 18 May 2009 09:01:57 -0400

> would seem better to drop those.

Agreed.