Subject: [mpls] Disposition of ITU-T LC comments on draft-ietf-mpls-loss-delay and draft-ietf-mpls-tp-loss-delay-profile

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 May 2011 14:58:09 +0100

The following is the disposition of Last Call comments received
from ITU-T SG15 on draft-ietf-mpls-loss-delay and
draft-ietf-mpls-tp-loss-delay-profile.

Stewart & Dan

=====

Comments received from ITU in : LS295 - Reply to the IETF MPLS
working group last call on "A Packet Loss and Delay Measurement Profile
for MPLS-based Transport Networks (ref #051.01)" (ref #051.02)

LS497 draft-ietf-mpls-loss-delay-01, section 2.7.3, Please add at the end
the paragraph "These concerns don't arise in MPLS-TP, because ECMP doesn't
apply there."

This was been added to draft-ietf-mpls-tp-loss-delay-Profile

LS497 draft-ietf-mpls-loss-delay-01, section 2.7.6, parag 4, Please add 
at the
end of this paragraph: "There is no limitation of direct LM in MPLS-TP, as
PHP is disabled and we cannot presume a control plane, which is the case
of LDP."

Text to address this has been added to draft-ietf-mpls-tp-loss-delay-profile

LS497 draft-ietf-mpls-loss-delay-01, section 2.7.7, There must be a clear
definition of which frames integrate the loss measurement scope, for 
MPLS- TP.
Please clarify.

This is explicitly stated in Section 4.2.8 of draft-ietf-mpls-loss-delay-02

LS497 draft-ietf-mpls-loss-delay-01, section 3.1, The need of 4 counters
is not clear: after the xLM message does A->B->A, the last (4th) 
measurement
is done at reception, so why writing the results into the PDU? The 4th
counter isn't really needed.

Technically this is correct provided the lifetime of the packet has ended
after the fourth TS or counter has been updated and for example the packet
is not being forwarded on for external post processing. Even in that case
however having the space in the packet for the fourth record may be
convenient for some implementations and does no harm.

LS497 draft-ietf-mpls-loss-delay-01, section 3.5.2, The addressing should
be aligned with the identifiers draft and not have a different 
implementation
for these PDUs.

The addressing TLVs specified in the draft-ietf-mpls-loss-delay are
generic. The address families defined in the IANA Address Families
Registry are sufficient for MPLS networks using IP addressing. If
a new address type is required this may be added to the registry through
the normal standards action process, and is outside the scope
of this draft.

LS497 draft-ietf-mpls-loss-delay-01, section 3.5.3, "Session Query 
Interval"
is useless in an NMS environment. Thus, please add to the end of this 
section
"Not applicable to MPLS-TP".

It is not obvious that that this field is unless in perpetuity in an NMS
controlled environment, but none the less the field is optional.

LS497 draft-ietf-mpls-loss-delay-01, section ..., Please consider a
new PDU: let's name it PRO-xLM+DM for now. The format could be the same
as DLM+DM (with correction suggested in section 3.1). Each time a frame
is transmitted, A writes into the PDU counters -A_TxP[n] the number
of packets Tx by A at the time this PDU is sent -A_RxP[n] the number
of packets Rx at A at the time it got a PDU from B -B_TxP[n] the
number of packets Tx by B the last time it Tx a PDU to A
We can thus do LM calculations both ways with half the PDUs. Loss
measurement @A would be:
A_TxLoss = A_TxP[n] - A_TxP[n-1] - (B_RxP[n] - B_RxP[n-1])
A_RxLoss = B_TxP[n] - B_TxP[n-1] - (A_RxP[n] - A_RxP[n-1])
(A_RxP is a counter internally kept @A) For unidireccional applications
(say B->A), A_TxLoss has no meaning and A only cares about B_TxP.

We have been aware of this possibility from the outset, but took the
view that the reduction in PDU frequency did not justify the
increased complexity of the protocols. Text has been added
to the draft (section 2.7) to explain the issues and describe a
method of making the measurement you request.