[rbridge] [Isis-wg] Why is MTU discovery important?
Ali Sajassi (sajassi)
sajassi at cisco.com
Wed Apr 15 19:42:15 PDT 2009
Don,
________________________________
From: Don Fedyk [mailto:don.fedyk at gmail.com]
Sent: Wednesday, April 15, 2009 5:53 PM
To: Ali Sajassi (sajassi)
Cc: Les Ginsberg (ginsberg); James Carlson; Sadler, Jonathan B.;
TRILL/RBridge Working Group; Silvano Gai (sgai); Radia Perlman;
isis-wg at ietf.org
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?
Ali
A few points in line. (this time cc the list)
On Wed, Apr 15, 2009 at 6:05 PM, Ali Sajassi (sajassi)
<sajassi at cisco.com> wrote:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090415/5b7845ef/attachment.html
More information about the rbridge
mailing list