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

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

On 1/27/11 3:34 PM, James Carlson wrote:
> 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.
>
Traditionally, we've put things that cause the implementation to fall over
into the Security Considerations section.  But heck, we could put it into
the Operational Considerations section.  Not a big deal....


> 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.
>
It's a point-to-point link specific issue.  In the IETF, it belongs in a
PPP document.  In the past, we had enough on our plates to ensure our
*own* protocols worked.  We didn't fuss about some other organization.


> 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.
>
It's a sad comment on the IETF that it's become so fussy about "turf"!

Remember the fights with ANSI T1 about defining a link layer over "their"
bits?  Or defining PPP over SONET/SDH (with two competing bodies)?

Let's just get the job done.


> 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.
>
I cannot "clearly" find that "responsibility" anywhere in RFC-1142.  Please
cite references.

Reminder: early PPP documents left a lot to the imagination of implementers,
especially error recovery.  It was more descriptive than prescriptive.  That
led to failure at Interop '90.

It is the responsibility of protocol designers to completely specify the
protocol, including error recovery!  Only after changing to a prescriptive
specification, PPP achieved wide-spread interoperability in '91.


> 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.
>
(Ahem) You seem to have forgotten the reasons for IETF existence, and the
fun times we had with ISO, DECnet, CLNP, etc.  (I have the T-shirt.)

Apparently, you've never operated an ISP, nor read the NANOG list.

Nor remember the problems with PPP multi-media bridges, as many companies
reused the same MAC for different media.


> 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.
>
If you insist on waiting for ISO to issue a specification, then arguably
you MUST wait to publish this document, as that would be a Normative
Reference....


> 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.
>
Speaking authoritatively on this matter, PPP was intended to be zero
configuration from the beginning!

But I did pioneer the Operational Considerations section to handle any
issues of configuration for special circumstances.


> 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.
>
We don't have consensus now.