Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation?

From: Curtis Villamizar <[email-masked]>
Date: Tue, 02 Mar 2010 23:24:43 -0500

In message <[email-masked]>
Alexander Vainshtein writes:
>  
> Curtis,
> Lots of thanks for a prompt response.
>  
> I agree that "non-pedantic MPLS-TP mode" will be probably quite
> useful.  However, for the purpose of interoperability, it would be
> nice to understand which of the MPLS-TP restrictions are "pedantic'
> and which are essential...

Since MPLS-TP is a subset of MPLS/GMPLS, an equipment vendor that
already has a MPLS/GMPLS implmentation has to add any new capability
defined as part of MPLS-TP, such as the OAM extensions and ability to
run without a control plane.

Any equipment vendor that currently does not have an MPLS/GMPLS
implementation would be wise not to implement only the subset that
follows all of the SHOULD statement as far as disabling MPLS/GMPLS
capability to get MPLS-TP.

> As for 3443 updating 3032: it took 2 years (3032 has been published in
> January 2001, 3442 - in January 2003).  So somebody should probably
> start writing an update to 5586 now...

In the case of TTL, the vendors just allowed configuration to enable
violating the spec to meet customer requests for the pipe model and
the internet-draft followed, and much later it became an RFC.

> Regards,
>      Sasha

This email isn't adding much except to serve as a reminder that at
least one major carrier has already indicated that they *will* be
using a control protocol and that there are other relaxations of
"pedantic MPLS-TP" that are also likely to be required in deployments.

Regards,

Curtis