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

Hi James,

I think your position below is reasonable. The System ID of an IS-IS
router is certainly not required to be any sort of MAC address, it
just has to be a 48-bit quantity unique among the IS-IS routers whose
link state entries need to be distinguished.

Perhaps Section 3, point 3, should be reworded to something like: "In
the case of an RBridge with only PPP links, the practice of using the
MAC address of an interface for the IS-IS System ID will not be
available. The implementor will have to use other means, such as
deriving a System ID from a MAC address allocated to the device as a
whole, to assure that it has a campus-wide unique System ID."

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 [email protected]

On Mon, Jan 24, 2011 at 8:16 PM, James Carlson <[email protected]> wrote:
> 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         <[email protected]>
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pppext
>
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext