Re: [Isis-wg] [rbridge] Why is MTU discovery important?

The whole loop issue that we are talking in here can also happen in IEEE
bridged network !!

Not exactly. Yes 802.1ah frames can be dropped but this does not mean a loop. It means certain frames will be dropped. If the frames were Bridge Protocol Data Units (BDPUs) yes things would get ugly. However BDPUs are not padded to my knowledge so they are unlikely to be dropped for this particular reason.

So to be precise here minimum MTU is affected by larger encapsulation agreed, but bridges don't have the designated forwarding mode of RBridges. Please be precise because this behaviour is unique to RBridges as far as I can tell. 802.1aq Shortest path bridging would use the normal mechanism for IS-IS MTU too small. SPB would use the usual response if an IS-IS adjacency does not come because of MTU or other issues up that particular link is disabled.

In 802.1ah, the Back Bone Core (BCB) bridges are of type S-VLAN which
means they can be limited to support max frame size of 1522 (1500 bytes
of payload + 22 bytes of header). However, if the original customer
payload is 1500 bytes, then with additional 802.1ah header, the total
frame size becomes more than 1522 and thus can get dropped by BCBs. This
drop of customer frames can include BPDUs which means if the customer
network is multi-homed to the service provider network (PBN/PBBN), then
it would put its multi-homed ports in the forwarding state and thus
causing a loop over the provider network.

The way IEEE is addressing this MTU issue is via 802.3as amendment (to
802.3 spec) which increases the frame size to 2000 byte (with 1500 bytes
for payload) - e.g., there can by 500 bytes of header and overhead.

So, a simple fix to this problem is to put a simple text in the TRILL
spec mandating that all Ethernet links to support 802.3as
maxEnvelopeFrameSize. This way, you don't need to do any fiddling with
IS-IS protocol.

Agreed this would reduce the likelihood but like I said before that Trill discovery should be outside IS-IS.

Furthermore, as Les mentioned, if the link can send some small sized
frames but not some other larger frames, then besides control plane
issues, you will have dropped frames in customer data which is not
acceptable - e.g., a service that can work for some frame size but not
some other ones !!

So to have a simple solution with a consistent and deterministic
behavior, we should expect that all Ethernet links behave the same
(e.g., they all support 802.3as).

I believe 802.3as will take some time to deploy. However I agree with your point in that there is always a minimum MTU that Trill could use consistently in a network. It could use 1492 if 802.3as is implemented if not it could probably use 1450. But that is separate from the Trill Discovery issue.

Regards,
Don

Cheers,
Ali

> -----Original Message-----
> From: rbridge-bounces at postel.org

> [mailto:rbridge-bounces at postel.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Wednesday, April 15, 2009 9:35 AM
> To: James Carlson; Sadler, Jonathan B.
> Cc: TRILL/RBridge Working Group; Silvano Gai (sgai); Radia
> Perlman; isis-wg at ietf.org

> Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?
>
>
>
> > -----Original Message-----
> > From: James Carlson [mailto:james.d.carlson at Sun.COM]
> > Sent: Wednesday, April 15, 2009 6:07 AM
> > To: Sadler, Jonathan B.
> > Cc: Silvano Gai (sgai); Les Ginsberg (ginsberg); Radia
> Perlman; isis-
> > wg at ietf.org; TRILL/RBridge Working Group
> > Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?
> >
> > Sadler, Jonathan B. writes:
> > > So why did James Carlson's implementation break when an 802.1ad
> Ethernet
> > bridge (i.e. without .1Q extensions) was put between two RBridges?
> Thats
> > what started this whole discussion...
> >
> > It's because slapping an extra header on top of a 1500
> octet message
> > tends to make it somewhat larger than 1500 octets. :-/
> >
> > Right now, TRILL headers are effectively part of the
> payload, as far
> > as ordinary bridges are concerned, and are subject to the MTU
> > restrictions. (Unlike "overhead" information between bridges, like
> > VLAN tags.) If we could have access ports agree to use
> 1478 instead,
> > we'd be able to meet a 1500 restriction between RBridges.
> >
> > Of course, that answer is just infeasible.
>
> Indeed - the point being that whatever bad things that happen
> to large size L2IS-IS PDUs will also happen to large size
> data PDUs that are TRILL encapsulated.
>
> So the question I would like folks to consider is whether
> there is a point in trying to utilize a LAN on which only
> small data packets can be guaranteed to be forwarded
> successfully? If the answer is "no" then I think the problem
> that needs to be solved is constrained and the set of
> appropriate solutions becomes more easily defined.
>
> Les
>
> >
> > In testing, I've found that some devices limit to 1500
> strictly. Some
> > are lax up to about 1536. Despite what standards may say about it,
> > there's a lot of odd stuff out in the field.
> >
> > --
> > James Carlson, Solaris Networking
> <james.d.carlson at sun.com>
> > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442
> 2084
> > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
> 1677
>
> _______________________________________________

> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg