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.

With max BPDU size and other overheads (mac-sec/nested level of mac-sec and/or nested level of .1ad/.1ah), it can get to or exceed that magical 1500 bytes !!

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.

I think the loop scneario is in common to both TRILL and IEEE. If case of TRILL, the c-bridged network is dual-homed to an Rbridged network and the Rbridge network via IS-IS DRB mechanism wants to only have a single port per VLAN in forwarding mode. In case of IEEE, the c-bridged network is dual-homed to a 802.1ad/802.1ah network and in port-mode the .1ad/.1ah network tunnels c-bridged network BPDU and the blocking is done by the c-bridged network. However, the loss of BPDUs causes the c-bridge network to activate its multi-homed ports and thus causing loop. The difference is that in case of IEEE scenario, the blocking is performed by c-bridged network and its BPDUs is tunneled by .1ad/.1ah network; whereas, in case of TRILL scenario, the blocking is performed by the Rbridged network and its is-is hello is tunneled by the c-bridged network. In either case, the loss of hellos or BPDUs causes loop.

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.

I am not talking about TRILL discovery. I am saying that TRILL should simply mandate the use of 802.3as which is now part of 802.3 base spec on all its Ethernet link to avoid this type of MTU issue and have a clean solution w/o fiddling w/ is-is. Otherwise, you can run into this type of issue when you turn on mac-sec on a link or some other features w/ additional header bytes.

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.

With 802.3as, TRILL can use payload of 1500 bytes and so no changes is required. Without it, then it should set the max MTU size to 1498 (1522-24) or 1494 (1518-24).

Cheers,

Ali

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