Re: [Pppext] proposed TRILL IS-IS System ID text

[James Carlson <[e-mail]>]

On 01/27/11 12:31, William Allen Simpson wrote:
> On 1/27/11 6:03 AM, William Allen Simpson wrote:
>> 3. An implementation that has only PPP links might have no previously
>> configured Media Access Control (MAC) that can function as an
>> IS-IS System ID. In this case, the System ID is formed by adding
>> a randomly generated 14-bit leading number (in place of an OUI) to
>> the link's unique LCP Magic Number. The Magic Number MUST be
>> unique for all links and all known link peers. This pseudo-MAC
>> MUST have both the "locally-assigned" and "broadcast/multicast"
>> (group) bits set to 1; that is, the least significant two bits of
>> the most significant octet are both set to 1.
>>
> Looking at this again, and remembering how fanatic the new RFC Editors (TM)
> are about abbreviations, probably needs to expand OUI, too:
> 
>                .... In this case, the System ID is formed by appending
>   the link's unique 32-bit LCP Magic Number after a randomly generated
>   14-bit number in place of an Organizationally Unique Identifier (OUI).
> 
> [Also makes the number of bits explicit: N/2**23 birthday attack;
> considerably less than having 2 identical MACs from the same vendor, or
> being killed by lightning.  Could put that in the Security Considerations?]

[Sorry for the duplicate on the PPP list; Thunderbird hurt me with the
CC-list again.]

Yes, I see where you're going with this.  I don't think it's a
"Security" issue.  It's actually a correctness issue -- if there are
duplicates, then IS-IS falls down.

That aside, what you're suggesting is still a bit uncomfortable to me.
You're essentially saying that this draft can forge up a new way of
creating IS-IS System IDs on its own just to be helpful.  I'm not so
sure that it can or should.  I think it's out of scope.

While I certainly agree that, if implemented properly (and if existing
system architectures allow implementation), what you're describing
should work nicely, I don't want to run afoul of the IS-IS folks by
tromping so squarely on their turf.

In particular, IS-IS simply mandates that System IDs must be unique
across the domain in which they're used.  Not that they're "extremely
unlikely to be duplicated" -- but that they're _never_ duplicated.  The
existing protocol clearly puts the responsibility for that in the hands
of system implementers, not the link layer designers.

Now, you're certainly within your rights to claim that MAC addresses are
a feeble mechanism, and you may well be right that there are systems
that duplicate them (though I can't say *I* have ever seen this), but
the ISO people behind IS-IS appear (to me at least) to think
differently.  It's not a matter of statistics, or of field experience,
but of specification.

Instead, I think the issue you're talking about is really a fundamental
issue in IS-IS itself, and is not one that is created by or altered by
or in any way related to PPP or TRILL.  IS-IS already supports
point-to-point links without PPP or TRILL.  And if you were to build an
IS-IS router with only point-to-point links and without some source of a
System ID, you would run into exactly this problem.  But as the links on
this hypothetical router are just plain old point-to-point links, you
would not have the benefit of the mechanism you're proposing to have to
this draft.

And the same problem occurs if you run an IS-IS router with only PPP
links using OSINLCP.  So, it's not specifically a TRILL issue.

It's the same problem, and it's not something that I think we ought to
be addressing.  We can certainly call it out, though.

I think that if this is to be addressed -- it's probably the least
important issue I can imagine in TRILL, and likely needs no fixing at
all, as I strongly suspect that real systems won't have the problem --
it should be addressed in the TRILL IS-IS document, or perhaps in the
base IS-IS documents themselves.  It's IS-IS itself that demands a
single unique System ID (PPP frankly doesn't care), and it's TRILL that
demands zero configuration.

At a minimum, I want to hear from IS-IS and TRILL experts before I go
ahead with proposing any new random-number-based System ID mechanism.
If they sign on, then I'll go ahead with it.

But my off-the-cuff guess is that they'll have objections, and more
objections probably aren't helpful in getting to consensus.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>