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

Hi,

On Mon, Jan 24, 2011 at 2:05 PM, William Allen Simpson
<[email protected]> wrote:
> On 1/24/11 1:29 PM, William Allen Simpson wrote:
>>
>> On 1/24/11 12:05 PM, James Carlson wrote:
>>>
>>> I agree that it'd be nice to fill in this hole, but I'm not so sure how
>>> to accomplish that task. I don't think IETF OUI plus LCP Magic Number
>>> works -- the Magic Number value is unique for a given endpoint on a
>>> given link, but is not guaranteed to be unique across a network. But
>>> the IS-IS System ID number does need to be unique across the network,
>>> and its construction based on MAC addresses normally protects that
>>> requirement.
>>>
>> It must be nice to live in a world with unique MAC addresses! In my
>> experience, I've run into rather a lot of them that are not -- and it
>> will be much worse in this cross-linked multi-media environment. Many
>> vendors think that it's OK to reuse the MAC address for different link
>> speeds and types.
>>
> 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.

You are looking in the wrong place. The unique System ID requirement
is an IS-IS requirement.

It is my impression that manufacturers of ISIS routers either allocate
a MAC address under their OUI to use as System ID or use the MAC
address of one of their interfaces. Maybe, in this instance, they are
more careful to not duplicate from some other box they built. But it
doesn't matter what they do. It's an IS-IS requirement and their
problem.

Maybe the draft should just say less about this.

Donald

PS: Current traveling so I'm a bit out of phase...

>> The only way that the Magic Number has any significant chance to ever be
>> non-unique would be a very large number of PPP-only bridges in the
>> network,
>> on the order of 2**16. Probably best to stick an IP router in there....
>>
> To elaborate, I've an old story to tell.  Once upon a time, Michigan State
> University supposedly had the world's largest bridged ethernet, covering
> many square miles.  Performance was abysmal.  But once I stuck a 286 box
> with KA9Q net (this was circa 1985) between the computing center and
> engineering, performance miraculously improved!
>
> (The problem turned out to be fragments inserted by the IBM in the
> administration building next door to the computing center.)
>
> Thus, I got the routing religion....  Never use a bridge where a router
> could be used instead.
>
> I really doubt we'll ever see more than one or two PPP-only Rbridges in a
> single installation.  The point being that PPP is vastly more robust than
> ethernet -- and you shouldn't let the good enough (ethernet) be the enemy
> of the better (PPP).
>
>> If the PPP-only bridges are talking to each other, there will *never* be
>> any non-unique numbers. That's the more likely case of centrally
>> located PPP-only bridges.
>>
> Of course, this assumes that the PPP Magic Number has been implemented
> correctly, and it checks the number against all its interfaces to avoid
> loops.  It also assumes you haven't deployed Junipers with the fairly evil
> "ppp magic-number ignore-mismatch".
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext