[trill] Fwd: Nickname Selection

[Donald Eastlake <[e-mail]>]

The following replies to Mahesh never made it to the TRILL WG list
because they were sent during the few hours the list was down.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

---------- Forwarded message ----------
From: Donald Eastlake <[e-mail]>
Date: Tue, May 8, 2012 at 2:27 PM
Subject: Re: [trill] Nickname Selection
To: Radia Perlman <[e-mail]>
Cc: Mahesh Akula <[e-mail]>, [e-mail]

Right, this is a typo. It is fixed in Section 4, Item 1, of the
Clarifications and Corrections draft:
http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-03.txt

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Tue, May 8, 2012 at 1:31 PM, Radia Perlman <[e-mail]> wrote:
> That looks like a typo to me.  I would assume it should say:
>
>> Each RBridge is responsible for ensuring that its nickname or each
>>       of its nicknames is unique.  If RB1 chooses nickname x, and RB1
>>       discovers, through receipt of an LSP for RB2 at any later time,
>>       that RB2 has also chosen x, then the RBridge or pseudonode with
>>       the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if
>
>
> *********
> I think the above line should be
> "the numerically higher priority keeps the nickname, or if"
>
> ***********************
>>       there is a tie in priority, the RBridge with the numerically
>>       higher IS-IS System ID keeps the nickname, and the other RBridge
>>       MUST select a new nickname.  This can require an RBridge with a
>>       configured nickname to select a replacement nickname.
>>
>
> On Tue, May 8, 2012 at 10:23 AM, Mahesh Akula <[e-mail]> wrote:
>> Hi Donald,
>>
>> In RFC 6325 3.7.3, i'm troubling understanding below statement, can you
>> please help clarify?
>>> Each RBridge is responsible for ensuring that its nickname or each
>>       of its nicknames is unique.  If RB1 chooses nickname x, and RB1
>>       discovers, through receipt of an LSP for RB2 at any later time,
>>       that RB2 has also chosen x, then the RBridge or pseudonode with
>>       the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if
>>       there is a tie in priority, the RBridge with the numerically
>>       higher IS-IS System ID keeps the nickname, and the other RBridge
>>       MUST select a new nickname.  This can require an RBridge with a
>>       configured nickname to select a replacement nickname.
>>
>
>> First it says, node with higher IS-IS ID keeps the nickname, then it says,
>> if there is a tie in priority then node with higher IS-IS system ID keeps
>> the nickname.  It gives meaning that IS-IS ID and nickname priority are
>> same??
>>
>>
>> Regards,
>>
>> Mahesh
>>
>>
>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>>