[trill] TRILL OAM Requirements: Third party debugging

[Thomas Narten <[e-mail]>]

I may just be misreading intent, but to be sure, I'd like to clarify
the following point. I had assumed that things like connectivity
testing, tracing, etc. would need to be supported from one RB to
another. That is, if I was on RB1, I could do a connectivity check to
any other RB. Or trace a path. However, any sort of test involving
connectivity from RB1 would need to be *initiated* from RB1.

There is some wording in draft-tissa-trill-oam-req-00.txt that could
be interpreted as it being a requirement that one should be able to
initiate an operation between RB1 and RB2 from some arbitrary third
RB. Is that the case? E.g.,:

>    OAM MUST have the ability to verify an RBridge RB1 is connected to a
>    specific RBridge RB2.

I would assume that the verifying that RB1 can reach RB2 is a
requirement "for RB1". that is, if I am logged into RB1, I can
initiate such a check to  any destination I want. But the above
definition  would also include being able to ask that question from
*any* RB. Is that the intention? 

>    An RBridge SHOULD have the ability to verify the above connectivity
>    tests on sections. As an example, assume RB1 is connected to RB5 via
>    RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to
>    RB5 connectivity on the section from RB3 to RB5. The difference is
>    that the ingress and egress TRILL nicknames in this case are RB1 and
>    RB5 as opposed to RB3 and RB5, even though the message itself may
>    originate at RB3.

Is the operator above "sitting at" RB3? I.e., is the test initiated
from RB3 and does it inject packet that have a source RB of RB1?
(That seems fine at one level because no special mechanisms are needed
to achieve this.)

But beyond that, I'm not sure what is envisioned, because if you did
(say) traceroute, TTL exceeded errors would go back to RB1, not
RB3. Same for any OAM response messages.

What is the thinking here?

Thomas