[rbridge] TRILL over IP

[Donald Eastlake]

Hi Jim,

On Mon, Nov 21, 2011 at 5:20 PM, James Carlson <carlsonj at workingcode.com> wrote:
> Donald Eastlake wrote:
>> Hi Jim,
>>
>> On Thu, Nov 17, 2011 at 7:37 AM, James Carlson <carlsonj at workingcode.com> wrote:
>>> I think the assumption necessary for those IP links is that they are all
>>> on a "private" IP network of some kind, or that there's never any
>>> connection from any IP router to any TRILL campus edge.
>>
>> I think you need to express the condition more carefully. If you have
>> a data center using TRILL, it would commonly have RBridges connected
>> to IP routers leading to the global Internet or at least an enterprise
>> Internet. It seems to me that the actual condition is that if there is
>> a path between two RBridge ports, the encapsulations needs to be
>> balanced between them (sort of like balancing parenthesis).
>
> I don't think that's good enough.  Any place where this IP-encapsulated
> packet can enter the campus TRILL area to be forwarded by TRILL itself
> is a risk.  That entry could be by accident, such as a long-lived
> forwarding loop.

But the parenthesis are not balanced in that case. If something goes
out a TRILL port that is TRILL over IP over Etherenet the port is sort
of (IP(Ethernet. If that is accepted by a port on the TRILL campus
that doesn't first strip Ethernet and then strip IP, that is to say is
not Ethernet)IP), you have a problem.

> IP has some protection against events like that, as does TRILL itself,
> but mutually-encapsulating protocols (somewhat by definition) do not.
>
>> For
>> example, if for some reason you had a port that was TRILL over PPP
>> over Ethernet and there was path from it to an Ethernet ingress
>> RBridge port, you could have a somewhat similar problem, although this
>> is much less likely than it would be with TRILL over IP.
>
> True, that's possible.  It would probably be wise to have a usage note
> in the TRILL over PPP text to say that using it with PPPoE or with L2TP
> running over a network that may include Ethernet is discouraged, due to
> the risk of mutual encapsulation, and lack of any coherent reason to do
> that.
>
>>> Those assumptions seem a bit harsh (and unverifiable), so I suspect
>>> you'll need some way to prohibit the loop from forming.  One way to do
>>> that would be to force TRILL ingresses to behave as a filter: if it's an
>>> IP packet, and the protocol/transport/port indicates that it's a TRILL
>>> packet, then drop.
>>
>> I don't think it is reasonable for the TRILL over IP draft to impose a
>> requirement on all RBridge ingress ports. However, it is reasonable
>> for it to impose a requirement on all RBridge IP ports. So I would
>> suggest a check before IP encapsulation to discard the frame if it is
>> a TRILL over Ethernet frame.
>
> The frame you're about to encapsulate badly won't look like TRILL over
> Ethernet.  Instead, it will look like TRILL over IP on Ethernet.  That's
> the failure case: where you get your TRILL-over-IP-on-Ethernet traffic
> entering the campus to be forwarded along just like all of the other
> blah-on-Ethernet traffic.

Right. My statement above is incorrect and should have said "TRILL
over IP over Ethernet" at the end.

> In a belt-and-suspenders way, I think it's wise for anyone dealing with
> this stuff to drop bits that can form an encapsulation-nesting loop like
> that.  I don't think (in a global sense) that it matters who is being
> "imposed" upon, because the RBridges shouldn't have feelings.

I wasn't talking about feelings. Since TRILL assumes all end station
frames are Ethernet, it just seems reasonable that there will
typically be more Ethernet ports than IP ports so, if additional
complexity is needed, it should be avoided at Ethernet ports and put
at other ports.

> But, yes, as long as the loop is cut in at least one place, the risk
> should go away.  At least until someone does something you didn't expect
> -- like Ethernet on L2TP on UDP on IP on Ethernet.  Then you're hosed.  :-/

Sounds to me like someone doing that already has a potential looping
problem even in the absence of TRILL.

Donald

> --
> James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>
>