Re: TRILL, IS-IS, and System ID

On 6/1/11 10:54 AM, James Carlson wrote:
> William Allen Simpson wrote:
>> Therefore, James is also wrong.  This is not an operator issue.  You
>> should *NOT* put this burden on operators.  It would really help for
>> anybody with aspirations of designing protocols to have actually been an
>> operator, and pay attention to discussions on the NANOG list!
>
> It's worth noting that I said "implementor" not "operator."  Perhaps the
> language I'm using isn't clear.  By "implementor," I mean the person who
> designs the hardware and software components that will be sold as a
> product claiming to support TRILL.  I do not mean the person who buys
> these products and installs them in a network.
>
When you say "implementor", are you proposing a penalty for failure?  How
do you enforce this as a protocol matter?  Is there an automated
discovery protocol in your draft?

Currently, every system that has an IEEE interface is supposed to pay
IEEE a fee.  For PPP, we decided long ago that we would not require IETF
implementers to pay a fee -- not to IETF or IEEE.

I formally object to a specification that has no method of resolving
duplicate identifiers.  I have proposed three (3) methods.


> Like you, I do not believe that it's appropriate or reasonable for
> general-purpose TRILL implementations to require any sort of action on
> the part of the person installing and using the equipment -- that is,
> the "operator."  I've never suggested that as a solution, so the straw
> man doesn't work here.  Nor do the ad-hominem jibes.
>
In point of fact, the enforcement burden falls on the operators, since in
the real world here and now there are duplicate MAC identifiers.  Let's
try to write specifications that actually handle known problems.

Any ad-hominem jibes would have to be a personal attack irrelevant to the
issue at hand.  That's not happening here.


> However, unlike you, I do not believe that the IETF must resolve this
> potential system-level design issue.  Instead, I still strongly prefer
> to leave it up to the people designing and building systems.  If they
> can't resolve this relatively simple problem in a reasonable way then,
> frankly, I have no faith that they can get any of the other million or
> so complex system design decisions right.
>
The IETF always used to handle any "system-level design issue" -- heck,
our bake-offs used to spend a lot of time on it!  That's one reason why
we actually talk about specifics of implementations.


> Most importantly, I don't want to be dictating anything about IS-IS
> design issues from within the PPP Extensions working group.  It's just
> not appropriate or even feasible.  That's why I agree with the ideas
> behind Stewart Bryant's text.
>
I'm sick and tired of the inter-working group silliness.  It's "I Plop
Down" (IP over Large Data Networks) all over again.  And really old
folks will remember the huge fight between PPP and ANSI T1 et alia, as
they didn't think IETF should specify anything over SONet without their
concurrence....


> All that said, I don't really care.  This is a tempest in a teapot.  I
> can mash together both texts if the Routing ADs are willing to accept a
> passing reference here to a draft that, in their words, hasn't even been
> considered by the IS-IS community.
>
Mash away.  Thank you.
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext