Hi Ali
Ali Sajassi (sajassi) wrote:
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:
Mick said "It is clearly unthinkable that
802.1 would specify a network arrangement requiring the use of BPDUs
which could not be sent."
Less likely is approaching zero.
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
Not true.Under such infrequent error conditions IEEE scenarios will
drop traffic. The loss BDPUs and other frames in this case is a normal
degrade of traffic. What this thread is about is that RBridges
connected to LANs of the C-VLAN variety assume they are the only
RBridge connected to the LAN and assume a forwarding behavior (DRB)
that can cause looping if this assumption is incorrect. Therefore it
is imperative that RBridges know that they are connected to the same
LAN even if they have some mismatch with the minimum MTU.
Very different in my books.
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
Again worlds apart. IEEE Provider Backbone Bridging was prototyped,
deployed and standardized without any fanfare on this issue. IEEE
802.3as was a proactive increase in the IEEE minimum frames size to
support a future where multiple encapsulation of the PBB variety could
be envisioned and still support the 1500 limit. There is no law that
say you cannot break your network with certain configurations but if
that network breaks it should do so gracefully.
3- In both TRILL and IEEE, customer data frames
that exceed 1500 bytes can be lost with again undesirable effect.
Thats why higher layer protocols support MTU detection and can adapt to
smaller MTU (usually). IS-IS does not at present adapt to different
minimum MTU on different links because once a minimum MTU is chosen any
IS-IS node may fill LSPs to that size. Ergo the MTU must be the same
on all IS-IS nodes. That is the other point on this thread.
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.
That is nice for new bridges and Provider Bridges (agreed) but it may
not be a condition that TRILL is willing to accept.
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 !!
Again the same point above, higher layer protocols adapt.
Regards,
Don
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>
|