Re: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02

[Dan Frost <[e-mail]>]

Hi Tom,

On Wed, Mar 02, 2011 at 04:46:03PM +0100, t.petch wrote:
> The choice of parameters here looks fine but the language that goes
> with it less so.
> 
> The protocol will still send the parameters in TLV but this I-D says
> that "When an LM session is externally configured, the values of
> several protocol parameters can be fixed in advance at the endpoints
> involved in the session, so that inspection or negotiation of these
> parameters is not required." " A simple implementation may assume that
> external configuration will ensure that both ends of the communication
> are using the default values for these parameters."
> 
> This seems to me too cavalier.  If one end is configured correctly for
> eg packet and the other incorrectly for byte and these recommendations
> are followed, then the protocol will work, will produce values and
> those values will be a complete nonsense.  Ditto the other parameters
> and DM.
> 
> I do not think we should be recommending something which is open to
> such errors.  There have been a fair number of posts on the mpls-tp
> list about misconfiguration, about the fact that it is always with us
> and that we need to be robust in the presence of it.  Here we seem to
> be digging a heffalump trap for mpls-tp to fall into.

Do you have some alternative text to propose that indicates the
desirability of common-sense sanity-checking without running afoul of,
for example, those who insist that they should not have to inspect
certain fields because an NMS will take care of everything?

-d

> Tom Petch