Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt]

[William Allen Simpson <[e-mail]>]

On 1/24/11 3:41 PM, James Carlson wrote:
> William Allen Simpson wrote:
>> I'm staring at the TRILL draft, and cannot find anything in the protocol
>> to detect, eliminate, or resolve duplicate System ID numbers.  Obviously,
>> I'm missing something.  Please advise.
>
> I don't believe that anything can or will do that.  It's assumed into
> existence, as far as I understand.
>
> The System ID is used (among other things) for pseudonode generation and
> TRILL nickname resolution.  If those aren't unique, then my
> understanding is that the network will fly to bits.
>
There is some text about resolving nicknames that aren't unique.  Nicknames
aren't deterministic on the System ID, though.  They're small, so they have
a 2*8 average chance of collision.  (Section 3.7)

I cannot find a description of pseudonode generation.  (Or even a
definition for "pseudonode".)


> I'm not the IS-IS expert here.  If someone else (preferably on the
> RBridge mailing list) has an opinion about running a TRILL IS-IS network
> where some of the nodes using only point-to-point links have System IDs
> that are possibly non-unique, then now is the time to speak up.
>
> But I certainly don't feel comfortable endorsing this sort of usage in
> the PPP TRILL draft without review by at least the TRILL group, and
> probably the IS-IS group as well.
>
OK, let's wait a bit.

The questions are:

  - How does TRILL handle System IDs that are not unique?

  - Are System IDs ever used in the ethernet source or destination fields?


> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
> check across all of the node's interfaces.  Off hand, I don't know of
> any that do that, and I do know of a few implementations where such a
> test would be architecturally impractical (if not outright impossible).
>
The whole point is to avoid loops.  It is "a unique number".  You cannot
avoid a loop with your *own* interfaces without checking against any
existing interfaces to see whether your chosen number is unique....

Certainly, I'd never expect connecting serial port 1 to serial port 2
on the same machine would ever pass the magic number test.

(Sometimes I wonder, how many more details must we write in specifications,
when something this obvious is missed by some implementers?)


> With Ethernet, the assumption is that MAC addresses among systems that
> speak IS-IS are unique per the standards.  Whether any vendor is able to
> achieve that and/or whether relying on MAC uniqueness is a smart thing
> to do is possibly an interesting topic, but I think is certainly one for
> a different mailing list.  It doesn't involve PPP.
>
I don't like assumptions.  That's a tautology.

If the proven existing MAC uniqueness in the field is already *less* than
known mathematical uniqueness of the PPP Magic Number, then there's no
PPP-specific issue to be solved.  In either case of conflict, then manual
configuration is required.

The chance of PPP collision is *much* rarer.  Automatic PPP configuration
should be part of this specification.