[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isis-wg] [rbridge] Why is MTU discovery important?
- To: "Don Fedyk" <don.fedyk at gmail.com>
- Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?
- From: "Ali Sajassi (sajassi)" <sajassi at cisco.com>
- Date: Thu, 16 Apr 2009 20:03:34 -0700
- Authentication-results: sj-dkim-3; header.From=sajassi at cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
- Cc: TRILL/RBridge Working Group <rbridge at postel.org>, "Les Ginsberg \(ginsberg\)" <ginsberg at cisco.com>, "Silvano Gai \(sgai\)" <sgai at cisco.com>, isis-wg at ietf.org, "Sadler, Jonathan B." <Jonathan.Sadler at tellabs.com>, James Carlson <james.d.carlson at sun.com>, Radia Perlman <Radia.Perlman at sun.com>
- Delivered-to: isis-wg at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=24599; t=1239937415; x=1240801415; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi at cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20<sajassi at cisco.c om> |Subject:=20RE=3A=20[Isis-wg]=20[rbridge]=20Why=20is=20MTU= 20discovery=20important? |Sender:=20; bh=gugqtqdz1K/Z3o/mH3r7O08VgoWvcgb840crAgRP75M=; b=Lvh+weFLsdQ0xSN9KpLNFVd6nT2MZB9pU8bYsRX4zxaLRWAr5uaG2y1fLw hjoJE6aK9+KpHug1ZhrT9GWa3H7jizUHugEm9gsgox7O761LBZFPk5hbevdu gsV/ada8mk;
- In-reply-to: <6fe277dd0904161924p1bbcb89cxc61f69e1da46a3b8 at mail.gmail.com>
- List-archive: <http://www.ietf.org/mail-archive/web/isis-wg>
- List-help: <mailto:isis-wg-request@ietf.org?subject=help>
- List-id: IETF IS-IS working group <isis-wg.ietf.org>
- List-post: <mailto:isis-wg@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
- References: <AE36820147909644AD2A7CA014B1FB5207AA4EEE at xmb-sjc-222.amer.cisco.com> <C600B8A3.675D%sgai at cisco.com> <5292FFA96EC22A4386067E9DBCC0CD2B260FB31294 at EX-NAP.tellabs-west.tellabsinc.net> <18917.56335.861406.673686 at gargle.gargle.HOWL> <AE36820147909644AD2A7CA014B1FB5207BD5970 at xmb-sjc-222.amer.cisco.com> <7F115A41909B2641A9550322C4DF9D56B081BA at xmb-sjc-22d.amer.cisco.com> <6fe277dd0904151752l47bfad04h671903b80f04a1c9 at mail.gmail.com> <7F115A41909B2641A9550322C4DF9D56B082BE at xmb-sjc-22d.amer.cisco.com> <6fe277dd0904161924p1bbcb89cxc61f69e1da46a3b8 at mail.gmail.com>
- Thread-index: Acm/A6AT5aIN5UoCSjCZJez7HnaXdAAABl1g
- Thread-topic: [Isis-wg] [rbridge] Why is MTU discovery important?
Don,
I thought we already discussed this on a separate
thread with Mick Seaman and I already pointed out how with the nested
mac-sec/.1ad/.1ah you can exceed that limit (if you also refer to
my email on this thread, I explicitly mentioned nested
mac-sec/.1ad/.1ah). Although it is granted that the scenario in
which customer BPDU size (over .1ah network) to exceed 1500 bytes is much
less likely than in TRILL, the points that I was making still
hold:
Similarity between the two:
1- In
TRILL, hello messages are tunneled over customer network; whereas, in IEEE,
customer BPDUs are tunneled over provider network. In either scenario, the loss
of hellos or BPDUs can cause loop although the likelihood of BPDU loss in
IEEE is much less than the hello loss in TRILL
2- In
both TRILL and IEEE, control packets can be lost because of
additional encapsulation overhead. In TRILL, LSPs that exceed 1500 bytes
will be lost with indeterministic effect on the network and in
IEEE MVRP, MMRP, and other control packets that exceed 1500
bytes will be lost with undesirable effect on the
network
3-
In both TRILL and IEEE, customer data frames that exceed 1500 bytes can be
lost with again undesirable effect.
I am
pointing out that the solution which is common between both IEEE
& TRILL is 802.3as which allows for about 500 bytes of
header overhead and avoid these encapsulation pitfalls.
Now
the other option for TRILL that we have discussed in this thread is
to reduce the MTU size (network wide) for both data & control packets
to allow for 24 bytes of TRILL overhead without changing existing IS-IS MTU
discovery/hello procedures but frankly I am wondering how feasible this can be
because some of the applications (clients of Ethernet) may assume MTU size of
1500 bytes !!
Cheers,
Ali
Ali
You are adding unnecessary confusion to this thread.
On the IEEE 802.1 Bridge Protocol Data Units (BDPU) point. BDPUs do not
grow to any where near 1500 bytes at this point in time. Therefore loss
of BDPUs or looping due to loss of BDPUs is not an 802.1 issue.
Possible Loss of Frames due to too small MTU is purely a TRILL & IS-IS
combination issue.
802.as is not a bad idea. 802.3as helps
applications that use Ethernet maintain the 1500 byte minimum MTU limit
by increasing the headroom of Ethernet.
Regards,
Don
On Wed, Apr 15, 2009 at 10:42 PM, Ali Sajassi (sajassi)
<sajassi at cisco.com> wrote:
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)
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
<snip>