[c-nsp] tag-switching mtu question

[David Freedman]

Here follows a summary of a discussion I had offlist with both Rodney 
Dunn and one of his colleagues about
the whole "mtu" / "tag-switching mtu" set of issues,their applicability 
to the PA-FE / IO-FE hardware and to AToM pseudowire:


--------------------------------------------------------------------------


1. Both the PA-FE and IO-FE series of interfaces are limited to
transmitting up to 1530 bytes of frame "on the wire"

2. "on the wire" refers to the size of the PDU (protocol data unit)
when we are talking about PE->P and P->P interfaces, we need to concern
ourselves with configuring the MTU or MPLS MTU to be the size of the SDU
(service data unit) and not the PDU

3. In the case of an 1500B IP payload with two labels (as per standard
RFC2547 L3VPN) on a PE->P or P->P interface the SDU is 1508 bytes so you
configure "mtu 1508" or "mpls mtu 1508"

The actual size of the frame (PDU) would be 1508+14 (1522) or 1508+18
(for dot1q) (1526) which does not violate the PDU limitation of 1530 on
these interfaces, the framing bytes which comprise the PDU are "implied"
by the driver and hence don't need to be configured.

4. PA-FE and IO-FE interfaces can only *currently* have their "mpls mtu"
set and not their "mtu"

5. The MPLS MTU was only an interim solution and will be dropped in
12.2(28)SB and 12.4T, as a result of CSCsc62963 (internal only)
the PA-FE and IO-FE interfaces will allow for "mtu" to be set
in order to allow the functionality to continue.
The "tag-switching mtu " or "mpls mtu" will hence no longer
be configurable over the actual interface "mtu"

Prior to this fix being implemented, we could have configured any "mpls 
mtu" on the PA-FE/IO-FE interfaces , but if it exceeded the 1530 PDU 
limit the frame was dropped.

An example would have been if you were to have four labels and the SDU 
is 1516 ("tag-switching mtu 1516" on PE->P or P->P interface)
which creates a PDU of 1534 on these interfaces , exceeding the 1530
limit for PA-FE or IO-FE interfaces and hence would have been dropped.

Rodney's view on the "tag-switching mtu" is the following:

"it was a hack and shouldn't have been allowed
in the first place. These changes are closing that hole with the goal
of having a more consistent cross platform implementation in regards
to MPLS MTU settings. "


6. When using L2VPN MPLS pseudowires (i.e EoMPLS) , the incoming circuit
from the customer (called the "Attachment Circuit" or "AC")
doesn't require any changing of the MTU at all if we are carrying the 
customer's IPoE (1500B IP packet inside Ethernet)

An example of this is where we carry a users Ethernet and dot1q
over an EoMPLS VLAN pseudowire.

The incoming interface from the customer sees :

- IP Payload (1500B)
- Ethernet Frame (14B)
- Dot1Q tag (4B)

Under circumstances such as above we dont need to accept anything
bigger from the customer then would be done normally (i.e without
EoMPLS) hence no MTU increase is required (the SDU is 1500B )

However on the PE->P and P->P interface we are also carrying:

- AToM Control word (4B)
- Customer's Ethernet Frame (14B)
- Customer's dot1q tag (4B)

So in total, the egress interface carries:

- Customer Payload (1500B)
- AToM Control word (4B)
- Customer's Ethernet Frame (14B)
- Customer's dot1q tag (4B)
- Service Provider VPN Label (4B)
- Service Provider LSP Label (4B)

1500+4+14+4+4+4 = 1530 which is the SDU, hence
on the PE->P and P->P interface, you are required to use
"mpls mtu 1530" (supported at the moment) or "mtu 1530"
(preferred method)

On the wire, the PDU is actually 1530+14 (1544) or 1530+18 (1548) (if
you have dot1q here) and exceeds the 1530 PDU limit so hence EoMPLS
carried on PE->P or P->P links are not suitable to be carried over PA-FE
or IO-FE interfaces (but can be carried everywhere elsE)


7. Where you carry something LARGER than the standard 1500 SDU for the
customer on the Attachment Circuit (ingress CE->PE) for example,
some MPLS labels (i.e customer runs MPLS over EoMPLS)
you can *only* increase the MTU , you can not increase the
"mpls mtu" here as its not relevant. (and support for this will be 
dropped anyway!)

The attachment circuit is not tag-switching and hence the
MPLS MTU is not relevant here.


8. Increasing the MTU on the attachment circuit is fine , you must
obviously increase the remote MTU (for the remote attachment circuit) in
order to comply with RFC4447.
If we dont, the PW will not be setup

9. This can pose a problem where the Attachment Circuit is actually a
dot1q subinterface. By increasing the mtu of the main (trunk) interface
you change the MTU for all the subinterfaces and hence where you have
Pseudowires configured for other customers you affect their setup (and
potentially break it)

An potential solution to this is a per-subinterface MTU, but most
ethernet interfaces that support dot1q do not currently support this.

BugID CSCeh27672 (externally visible) has been raised to deal with this
and is in "Assigned" state, but no progress has been made on it.

I have raised a TAC case with regards to this BugID and asked for
progression on it, with two potential solutions:

a. Allow per-subinterface MTU for the purpose of PW setup (even if its
meaningless elsewhere)

or

b. Allow override of the RFC4447 MTU checking as per l2tpv3 PW setup



-----------------------------------------------------------------


Kind Regards,

David Freedman