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

From: William Allen Simpson <[email-masked]>
Date: Thu, 27 Jan 2011 06:03:45 -0500

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.

...

    Operational Considerations

       Although the probability of conflict with another IS-IS System ID
       is minuscule, each implementation MUST have a configuration option
       to override the System ID.

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 27 Jan 2011 12:31:25 -0500

> 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?]

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jan 2011 15:33:02 -0500

> being killed by lightning.  Could put that in the Security Considerations?]

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         <[email-masked]>

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jan 2011 15:34:36 -0500

> 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.]

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 28 Jan 2011 12:47:15 -0500

> 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....

> 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.

> 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.

> 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.

> differently.  It's not a matter of statistics, or of field experience,
(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.

> 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....

> 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.

> objections probably aren't helpful in getting to consensus.
We don't have consensus now.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 28 Jan 2011 18:38:50 GMT

> From: William Allen Simpson <[email-masked]>

> configuration from the beginning!

That sort of comment was inappropriate in the 1990s and is still
inappropriate.  Mr. Simpson's efforts to educate us in the histories
of the IETF, PPP, the PPPEXT working group, SLIP, ISO and ITU conflicts
and so forth are irrelevant.  They're also unnecessary if the rest of
us who could speak just as authoritatively on PPP have not slipped into
senile dementia.  They useless if we have.

> We don't have consensus now.

That is certainly not clear and I think it is wrong.  We have one person
objecting to the thrust of the TRILL draft and trying to use the eventual
RFC to fix a potential or possible IS-IS configuration, installation,
or implementation error.  Consensus is not unanimity.  More precisely,
we do not have consensus for significantly changing the TRILL draft to
fix IS-IS.

I can't seem to get excited about TRILL, but I am convinced that fixing
any lack of IS-IS auto-configuration or uniqueness of IS-IS identifiers
is outside the scope of the PPPEXT working group and of this draft.
It's not PPP that breaks if IS-IS's promise, premise, or demand for
uniqueness is broken but IS-IS.  Perhaps the TRILL document "call out"

> > be addressing.  We can certainly call it out, though.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Fri, 28 Jan 2011 14:10:12 -0500

> *own* protocols worked.  We didn't fuss about some other organization.

The leap I think your argument might be making is that PPP is the only
possible point-to-point protocol over which IS-IS would run, and that
this is thus the right place to write this specification.

I strongly disagree.

The existing OSINLCP in PPP allows you to run IS-IS over PPP *TODAY*,
and the problem you're citing isn't solved.  Moreover, it isn't solved
even if I put this special text into the draft under consideration,
because this draft addresses only TRILL usage of PPP.  And it's not
fixed when IS-IS is run over _other_ point-to-point media.

In other words, it's an IS-IS issue, not a PPP issue.

> Let's just get the job done.

If you don't like the word, then I can certainly use another.

IS-IS operation is simply outside the purview of the IETF PPP Extensions
working group.  It's got nothing to do with us.  We don't define IS-IS
any more than we define SONET/SDH.  We just live with it.

I believe the best we can reasonably do here is say, gee, IS-IS people,
it looks like you have a possibly ugly hole in your specification.  If
you care about it, please fix it, because we can't fix it for you.  As a
bonus, we can offer you these bits from our neck of the woods, if
they'll help.

> I cannot "clearly" find that "responsibility" anywhere in RFC-1142.  Please

How about 7.1.1, where it's defined?

  ID, a 6 octet system identification. Correct operation of the routeing
  protocol requires that this field be unique within an area for End
  Systems and Level 1 Intermediate systems, and unique within the
  routeing domain for Level 2 Intermediate systems.

It's unique; end of story.  It doesn't say "you must demand this from
your link layer interfaces."  It doesn't say "you can optionally create
one out of thin air by generating random numbers if you want."  It
doesn't even say whether administrative intervention is needed or desired.

That puts it in the hands of the implementer.

> specification, PPP achieved wide-spread interoperability in '91.

I agree, and I believe I've done that here.

I think the only way I can comply with your demand is to put text like
this into the draft:

	If the TRILL implementation using PPP links also uses IS-IS,
	then the IS-IS implementation MUST have a network-wide unique
	System ID.  Commonly, this is derived from a link layer MAC
	address (which is not available on PPP) or from a system-wide
	MAC address (which may be available on certain systems).
	Acceptable means of determining a System ID for this use are
	covered in the IS-IS and TRILL IS-IS documentation.

In other words, call out the issue, and effectively outlaw (via "MUST")
the degenerate mode of operation where a system has only PPP links and
_also_ has no means of getting a system-wide identifier.

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

I refuse to respond to ad hominem attacks.  Stick to the topic, please.

> you MUST wait to publish this document, as that would be a Normative

I don't understand what you're saying.  How is it Normative?

What part of this specification changes in any way depending on what the
IS-IS folks decide to do about this decades-old hole in their document?

Do any of the PPP bits on the wire change as a result?  Are there any
configuration option changes?  Or new packet formats?  Or state machine
variations?

I see no dependency here at all, so no way the reference you're
requiring could be Normative.  It does not define the protocol.

> We don't have consensus now.

In observing the TRILL discussions with the IS-IS group, it seemed clear
to me that making changes to IS-IS (beyond adding a few new data types)
was not a substantial area of interest.

I still don't see why any sort of System ID fabrication mechanism needs
to be part of this specification.  It's not a requirement that any given
TRILL implementation uses IS-IS.  And even if a given TRILL/IS-IS system
doesn't have PPP links, the implementor already has substantial issues
to resolve in getting the System ID right.  (E.g., dealing with hot-swap
hardware is a very interesting problem.)

I do not believe it's PPP's fault if a given IS-IS implementation can't
get the System ID it needs to run.  It wouldn't be Ethernet's fault,
either, if the implementor doesn't know how to deal with hot-swap, and
uses a "bad" MAC address as a result.

I think the fix you're proposing just polishes the tip of an iceberg.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 30 Jan 2011 22:39:13 -0500

On 01/27/11 12:31, William Allen Simpson wrote:
>> the link's unique LCP Magic Number.

I think it is a very bad idea to mandate this method which, as far as
I know, is radically different from all methods currently in use. For
example, some manufacturers just allocate a 48-bit number related to
their MAC address space for each switch and use that as the System ID
regardless of the type of any switch interfaces or the MAC addresses
of any interfaces that have MAC addresses. Why should they change
their behavior just because it happens that they have all PPP
interfaces? Having all PPP interface is a state that could change
dynamically.

I would suggest, at a minimum, the following changes:
- Replace the beginning with something more like "An RBridge that has
only PPP interfaces might not have a conveniently available MAC
address from which a System ID that would be unique across the campus
can be derived. A possible statistical source of a System ID that
implementors may wish to consider would be formed by ...."

- Add a reference to [RFC4086] after "randomly generated".
- Add a reference to [RFC5342] after "OUI".
- The reference to "the link" is obviously problematic if their are
more than one. Suggest changing to "a link".

Even with the above changes, I'm pretty dubious.

>>   The Magic Number MUST be
>> unique for all links and all known link peers.

My impression from other posts is that you are not just trying to
change how people do IS-IS, but aspects of how they do PPP as well.

>>   This pseudo-MAC

Sure.

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