Subject: [rbridge] isis layer 2 question

From: "Jeff Pickering" <[email-masked]>
Date: Thu, 11 Feb 2010 12:14:12 -0800

Correct me if Im missing something (wouldnt be the first time), but it appears that nickname data
appears only in lsps, not trill hellos. Yet a nickname is required in the appointee field when a drb
sends a appointed forwarders subtlv in a hello (section 2.3.3). Sure you can extract this from an
lsp you recieve from a non-access port, but that seems awfully cumbersome. Especially since
nicknames are subject to change. Is this really what we want? Why not put a nickname somewhere
in the hello?

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 11 Feb 2010 16:27:07 -0500

Hi Jeff,

Nicknames are used for forwarder appointments to save space. A nickname is
just an abbreviation for a System ID.

Putting the nickname of the sending RBridge in the TRILL Hello would be
redundant since you can see the SystemID in the Hello header and any RBridge
can map SystemIDs to nicknames using their copy of the link state database.
The problem with having information redundantly is what to do when the
redundant copies are inconsistent?

Say you receive TRILL Hellos from an RBridge with System ID "X" that say its
nickname is "Y" but the nickname corresponding to that System ID in the link
stat database is "Z". What do you do then?

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 11 Feb 2010 23:58:53 -0500

Sorry, I had forgotten that there was an additional reason to include an
RBridge's nickname in TRILL Hellos that it sends: for support of end
stations that want to originate TRILL encapsulated data frames. You don't
want to require such an end station to maintain the link state database so
it needs some other way to learn the ingress RBridge nickname. Such an end
station originated encapsulated data frame would, at least on a
point-to-point link, be discarded by default but base protocol draft Section
4.6.2 processing list item 8 specifically permits an RBridge to be
configured to process such frames. The ability to so configure a port is
also mentioned in base protocol draft Section 5.2.

The inclusion of one nickname in the TRILL Hello is actually provided for in
the just posted draft-ietf-isis-layer2-02.txt draft in Section 2.7
"TRILL Neighbor TLV" which also gives this rationale for this field.

    Two possible changes/problems:

1. I actually don't think the TRILL Neighbor TLV is the best place for this
field as that TLV need not be included exactly once in every TRILL Hello. I
think a better place would be in the sub-TLV described in the isis-layer2
draft in Section 2.3.1 and currently called "Special VLANs and Flags
sub-TLV" because that sub-TLV occurs once in every TRILL Hello. (This would
actually be a change in the isis-layer2 draft.)

2. The inclusion of the sender nickname in TRILL Hellos should be mentioned
in the TRILL base protocol draft in Section 4.4.2.

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

On Thu, Feb 11, 2010 at 10:12 PM, Radia Perlman <[email-masked]>wrote:

> Seems harmless, and a good idea, to put "what my (main) nickname is" into
> the Hello.
> (the case of multiple nicknames is really rare...just to allow the campus
> to compute multiple
> trees rooted at you). I can't see any reason to put multiple nicknames into
> a Hello, but
> again, it would probably be harmless to allow it.
>
> Radia
>
>
>
>
> On Thu, Feb 11, 2010 at 12:14 PM, Jeff Pickering <[email-masked]>wrote:
>
>>