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

[James Carlson <[e-mail]>]

William Allen Simpson wrote:
> On 1/27/11 3:34 PM, James Carlson wrote:
>> 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.

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.

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

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.

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

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.

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

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.

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

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

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.

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