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

[James Carlson <[e-mail]>]

On 1/24/11 5:44 PM, William Allen Simpson wrote:
> 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".)

It's part of RFC 1142.  I'm no IS-IS expert; it could possibly be just a
LAN-type feature.

The bottom line, though, is that I'm not willing to define a new mode of
operation for IS-IS on my own.  If there's some documentation of how
existing IS-IS systems with only point-to-point links operate without a
System ID, I'll be happy to provide a pointer to it along with an
appropriate synopsis to make it as clear as possible.

I am unable to locate any documentation of that sort.  If you have
pointers, please supply them, and I'll incorporate.

I wrote this draft as a favor to the RBridges chair to describe how the
protocol would work on some medium other than Ethernet.  The TRILL
protocol is designed so that it should be medium-agnostic (at least on
the transport side), but without an existence proof, it's hard to know,
and that's what this draft helps accomplish.

But I don't intend this draft as an extension or modification of IS-IS
in any way.  If extensions are required, then I think it would be best
to withdraw the draft and call it a day.  Someone else will have to
design whatever extensions you and the other reviewers feel are
necessary.  (I don't believe any such extensions are required, but if
that's the case, then I'm out.  I can't do that work.)

> OK, let's wait a bit.
> 
> The questions are:
> 
>  - How does TRILL handle System IDs that are not unique?

I do not know.  But I do know that RFC 1142 goes out of its way to say
that MAC addresses are unique, and that System IDs must also be unique.
 As far as I can tell, it's just assumed.

But this is *not* the IS-IS working group.  I think any questions about
how IS-IS does or does not work really ought to be directed to that
group.  I can't answer them in any reasonable way, and I'm pretty sure
that questions like that are just plain out of scope for this draft.

For that matter, this draft also doesn't address TRILL itself.  It only
addresses the operation of TRILL over PPP links.  If there are design
problems in TRILL itself -- if there needs to be some magic in TRILL
that checks for the "impossible" duplicate System IDs -- then I believe
that this is a generic issue with TRILL, and it should be addressed
outside the scope of the last call for this draft.

If there's a fix to the problem you're describing, then surely it's not
dependent on PPP for operation.  Right?

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

Not that I'm aware of.  They are used in the generation of LSPs as part
of IS-IS, though.

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

It's to avoid looped-back interfaces.  That's exactly what the RFC says.
 Not "avoid loops."  The RFC goes to great length to describe when and
why an implementation must generate a new Magic Number value due to
conflict, and at no point does it describe comparisons against any value
except the two values used by the two peers on the link.

I agree that it'd be nice to have it do more, and that what you're
suggesting sounds reasonable.  However, it's certainly not what the RFC
says.

And worse still, even if the RFC were to describe the mechanism you're
suggesting, IT WOULD NOT HELP!  The requirement in IS-IS is for
network-wide uniqueness, and merely checking all of your own links --
but not those of all of the nodes in the network -- is insufficient to
meet that goal.  Nothing PPP does can help with that.

Thus, I believe this entire discussion about the operation of the LCP
Magic-Number option is without a point.

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

If you'd like to publish an update to RFC 1661 with this sort of
restriction, that sounds fine to me.  For what it's worth, though, I
can't say I know of any implementations that will pass this new stricter
test.

In particular, the common CMU/ANU/samba.org pppd implementation would
not pass.  It has no means of comparing Magic-Number option values
across links.  The control portion of each link runs in a completely
different address space -- different processes.  It'd require a database
similar to the one currently used for RFC 1990 E-Ds and MP in order to
implement it, and given the sorts of problems seen with that, it's not
what I'd call an improvement.

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

I still don't understand why this draft has to define this new special
usage.  We're talking about a corner case out of a corner case -- a
special TRILL-speaking system with PPP links but that has zero Ethernet
interfaces.  Who is going to build such a beast?  And why?

In the unlikely case that someone does build that thing, I'd be happy to
let that person define exactly how the required IS-IS System ID is
computed, formed, configured, guessed, or drawn carefully out of the
ether.  For the simple case of allowing a TRILL-speaking system that
already has its own means of deriving a System ID (whatever that may be)
to use PPP links between other cooperating systems, I believe the
existing text is sufficient.

To be clear: TRILL over PPP allows the packets to be exchanged in a
reasonable manner.  Unlike Ethernet, it does not come with a burned-in
"guaranteed globally unique" MAC address, and thus any existing text in
TRILL and/or IS-IS documents that assume the existence of such an
address on at least one link in the system -- such as section B.2.1.3 of
RFC 1142 -- will have to look elsewhere for that value.  PPP can't
supply it.

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