Subject: Re: [rbridge] TRILL base protocol -15 to -16, changes to Section 4

From: Michael Kantowski <[email-masked]>
Date: Mon, 22 Feb 2010 07:08:10 -0800 (PST)

Oh, I guess this is addressed in 

4.3 Inter-RBridge Link MTU Size.

Mike Kantowski

________________________________
From: Michael Kantowski <[email-masked]>
To: [email-masked]
Sent: Mon, February 22, 2010 8:39:37 AM
Subject: Re: [rbridge] TRILL base protocol -15 to -16, changes to Section 4

Would rbridges send back any icmp or other type messages in order to help facilitate pmtud?  Do you foresee any issues with pmtu in general with this additional encapsulation?  Or would we continue to rely on routers for this messaging, business as usual...?

(I am likening this the situation found with IPsec tunnels over ethernet where you need to set the mtu on tunnel interfaces to something like 1400 in order to keep the packet sizes below the ethernet mtu.)

thanks!

Mike Kantowski

________________________________
From: Donald Eastlake <[email-masked]>
To: [email-masked]
Sent: Mon, February 22, 2010 8:05:49 AM
Subject: Re: [rbridge] TRILL base protocol -15 to -16, changes to Section 4

On Sat, Feb 20, 2010 at 12:11 AM, Donald Eastlake <[email-masked]> wrote:

Changes to Section 4 of version -15
>...
{2} MTU
>
>
>Add to Section 4.8.1: "Native frames that, after TRILL encapsulation,
>exceed the MTU of a link on which they would be sent will generally be
>discarded."
>
>
>...

The Section reference above should have been 4.3.1, not 4,8,1.

Donald

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Feb 2010 08:53:55 -0800

> 4.3 Inter-RBridge Link MTU Size.

Yes.

FWIW, as an L2 device, a TRILL device should never send an ICMP message;
that's something L3 devices send.

Joe

> ------------------------------------------------------------------------
> *From:* Michael Kantowski <[email-masked]>
> *To:* [email-masked]
> *Sent:* Mon, February 22, 2010 8:39:37 AM
> *Subject:* Re: [rbridge] TRILL base protocol -15 to -16, changes to
> Section 4
> 
> Would rbridges send back any icmp or other type messages in order to
> help facilitate pmtud?  Do you foresee any issues with pmtu in general
> with this additional encapsulation?  Or would we continue to rely on
> routers for this messaging, business as usual...?
> 
> (I am likening this the situation found with IPsec tunnels over ethernet
> where you need to set the mtu on tunnel interfaces to something like
> 1400 in order to keep the packet sizes below the ethernet mtu.)
> 
> thanks!
> 
> Mike Kantowski
> 
> ------------------------------------------------------------------------
> *From:* Donald Eastlake <[email-masked]>
> *To:* [email-masked]
> *Sent:* Mon, February 22, 2010 8:05:49 AM
> *Subject:* Re: [rbridge] TRILL base protocol -15 to -16, changes to
> Section 4
> 
> On Sat, Feb 20, 2010 at 12:11 AM, Donald Eastlake <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> ------------------------------------------------------------------------
>

---

From: Anil Rijhsinghani <[email-masked]>
Date: Mon, 22 Feb 2010 14:24:52 -0500

> > 4.3 Inter-RBridge Link MTU Size.

I thought path PMTU discovery was a non-goal of the TRILL
mechanism which is IS-IS specific, 4.3.1 is clear on this: 'Sz has no
direct effect on end-stations and is not directly related to any
end-station to end-station "path MTU". Methods of using Sz or any link
MTU information gathered by TRILL IS-IS in the traffic engineering of
routes or the determination of any path MTU is beyond the scope of
this document.'

> that's something L3 devices send.

There may be exceptions, pings for example. Also, PMTUD has been
shipped in bridges which fragment while transparently connecting
LANs with different MTUs.

Regards,
Anil

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Feb 2010 13:49:32 -0800

> routes or the determination of any path MTU is beyond the scope of

Right. I'm agreeing that 4.3 addresses this.

> LANs with different MTUs.

Pings are L3. L2 devices should not be responding or involved directly.

Various L2 devices snoop and/or participate in L3 protocols. Rbridges do
so for IPv6 multicast (as noted in Sec 4.7), but not for other protocols.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Feb 2010 15:06:44 -0800

Donald Eastlake wrote:
> On Mon, Feb 22, 2010 at 4:49 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Anil Rijhsinghani wrote:
>     > ...
> 
> [Actually for both IPv4 and IPv6 multicast...] 

Sorry - caught that. Yes, both IPv4 and IPv4.

> Just speaking as an individual, I don't currently think RBridges should
> mess with L3 ping or ICMP.
> 
> But there are people who want similar capabilities at L2. For example,
> BFD loopback to support faster failover. Or some as yet to be specified
> L2 trace route or error reporting so, for example, an ingress RBridge
> might hear about problems in forwarding frames it had encapsulated...

If there were L2 versions of these protocols, they would provide an L2
service, capability, or optimization. They would NOT directly interact
with their L3 counterparts.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 22 Feb 2010 18:00:02 -0500

Just speaking as an individual, I don't currently think RBridges should mess
with L3 ping or ICMP.

But there are people who want similar capabilities at L2. For example, BFD
loopback to support faster failover. Or some as yet to be specified L2 trace
route or error reporting so, for example, an ingress RBridge might hear
about problems in forwarding frames it had encapsulated...

Thanks,
Donald