[j-nsp] BGP VPLS MTU for pseudowires

Saku Ytti saku at ytti.fi
Tue Mar 6 06:07:59 EST 2018


What I mean some vendors report L3 MTU, some L2 MTU some something in
between. So even if the actual MTU is same the signalled MTU's may
mismatch and pseudowire fails to come up.

So only reasonable thing is just to make sure the pseudowire MTU
signalling does not matter, it gives no guarantees anyhow, as
corollary to above is, only way to get pseudowire to come up withy
lying, is to configure mismatching MTUs, so that the reported MTUs
match!


It seems vendors disagree on how MTU is calculated based on this paragraph:

   -  Interface MTU sub-TLV type

      A 2-octet value indicating the MTU in octets.  This is the Maximum
      Transmission Unit, excluding encapsulation overhead, of the egress
      packet interface that will be transmitting the decapsulated PDU
      that is received from the MPLS-enabled network.  This parameter is
      applicable only to PWs transporting packets and is REQUIRED for
      these PW types.  If this parameter does not match in both
      directions of a specific PW, that PW MUST NOT be enabled.



Also the PE visible MTU may not be what's on the customer attachment
port, due to various reasons. So it's just really useless thing for
signalling to check.


On 6 March 2018 at 11:57,  <adamv0025 at netconsultings.com> wrote:
>> Of Saku Ytti
>> Sent: Tuesday, March 06, 2018 8:32 AM
>>
>> Hey Dejan,
>>
>> I wouldn't worry about this. The MTU check never should have existed in
>> pseudowire signalling. It's even vendor dependent how they calculate they
>> MTU, so you might have exactly correct MTU in A-B end, but you will get
>> MTU mismatch because they calculate different thing in A and B end.
>>
> When you say exactly correct do you mean exactly same "customer MTU" A-to-B
> and B-to-A?
> By "customer MTU" I mean what's left for customer after any service provider
> encapsulations on either end are excluded.
> For p2p ckts I get it that if just one end represents the correct "customer
> MTU" and "customer MTU"="customer MRU" on this one end and the other end is
> higher or same then that should do, but for multipoint services you better
> set the same "customer MTU" on all circuits.
>
> Customers don't care about how MTU is calculated on either end and what
> encapsulation you need to impose on either end to provision the service,
> they only care about being able to TX/RX at contracted MTU value on each
> circuit (and they do test with JDSUs at each end).
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>
>



-- 
  ++ytti


More information about the juniper-nsp mailing list