Responses to IETF LC comments on draft-ietf-mpls-tp-oam-requirements-03)

[Martin Vigoureux <[e-mail]>]

all,

this long e-mail contains a synthesis of the comments posted
on this list with answers for each of them or groups of them
when similar.

regards,
martin


===========
Jing Ruiquan said:
> As a carrier, we think it is very important to operate MPLS-TP OAM
> with a behavior that is consistent with transport network operations.
> So we propose the following requirement to be added to MPLS-TP OAM
> requirements draft:
>
>   It MUST be possible to operate the MPLS-TP OAM protocols, which
>   satisfy functional requirements that are common to general
>   transport layer network (i.e., independent of technology), in a
>   way that is similar to the way equivalent mechanisms are operated
>   in other transport layer technologies (e.g., SONET/SDH, OTN and
>   Ethernet).

Adrian said:
> The problem is that what you have written is very widely scoped and
> would require an implementer to go and find out (from somewhere) what
> the actual requirements are. We need specific and tightly scoped
> requirements. That means that you need to document the individual
> "functional requirements that are common to general transport layer
> networks" and the mode of operation that would be "similar to the []
> equivalent mechanisms [] in other transport layer technologies."
>
> It is simply not enough to say "I want the OAM to be sort of like
> something else." While I can sympathise with your desire, I could not
> produce a product that was certain to meet your requirements.
>
> So, I suggest that what you need to do is list specific requirements
> for functions or operational behavior that you believe are not already
> covered by this document. I know that the authors were trying to make
> the MPLS-TP OAM "similar" to both general packet networks and general
> transport networks - but they tried to do this by listing the detailed
> requirements one by one.

Jing replied:
> IMHO, I think most of the requirements in the document are actually a
> little bit generic. And requirement 21 of RFC 5654 is so generic as
> well. The proposed requirement is specifying what that requirement
> means in the context of OAM.

Please see at the end of the e-mail the Resolution 1

> Another comments is about the Diagnostic Tests which include loopback
> and estimation of bandwidth. From a carrier's viewpoint, I think
> loopback and Route Tracing belonging to the same type of function,
> Bandwidth Measurement and Packet loss Measurement belonging to the
> same type of function. So I propose to make loopback as a individual
> requirement just as Route Tracing.

There is a recurrent misunderstanding about loopback.
Loopback (i.e., ping) is covered in Section 2.2.2 as part of CC.
The loopback mentioned in Section 2.2.4 is a diagnostic test where
and end-point connects both ends (source and termination points)
of an e.g., LSP thus forming a loop. Please see Resolution 2.


===========
Rui Costa said:
> SDH and EoSDH networks are widely used by Portugal Telecom
> Comunicacoes (PTC) and TMN (respectively the incumbent operator in
> Portugal and PT group's mobile operator), as well as foreign PT's
> clients (Brazilian "Vivo", for instance). These operators are used
> to both SDH and Ethernet's OAM paradigm. We ask you therefore to
> consider that MPLS-TP OAM protocols MUST allow equivalent OAM
> mechanisms.
>
> Being more precise, we would like to use the same protocol messages,
> to give/have the same "touch&feel" we had in SDH and for less time
> in ETH.

We understand the need for commonalities (see Resolution 1) however
we would like to point out that identical PDU is a solution not a
requirement, furthermore, identical PDU do not guaranty identical
behaviours.

> In SDH...    - it allows you at each end to check you have signal
> reception and notify the other end when you don't (RDI)

RDI is covered in the functional requirements.

> - it does so at different levels (in SDH you can have it both for
>   each VC and for the STM)

If the intended meaning was that in the case where there is nesting
(e.g., LSP in LSP, or PW in LSP) it must be possible to run OAM on
the inner and outer entities separately then this is covered in the
draft:
    Since LSPs may be stacked, the protocol solution(s) MUST be
    applicable on any LSP, regardless of the label stack depth.
combined with:
    Furthermore, any OAM function applied to segment(s) of a PW or LSP
    SHOULD be independent of the OAM function(s) applied to other
    segment(s) of the same PW or LSP.

> - it has a means by which to exchange an APS protocol

There is no APS related requirement as it more falls in the scope
of survivability than of OAM.

> - MEF defined performance monitoring functions for frame loss
>   measurement [FL], delay measurement, delay variation measurement,
>   which are also addressed in Y.1731

As suggested during IESG Review, references for loss and delay
(RFC 2679, RFC 2680 and RFC 2981) will be added to the document.

> The main reason to use the same PDUs as in Y.1731 is probably the
> same I guess and respect in RFC5654 2nd general requirements:
> economy.

Economics are a valid consideration but, as previously stated,
same PDUs do not guaranty same behaviour.

>> I would also like to point out that the mechanisms in Y.1731 are
>> sufficiently simple to allow some "hardwarization", which would ease
>> more vendor's implementations to converge to the 50ms protection
>> timescale, allowing a way to do this in a cheaper, more scalable and
>> miniaturized way.

There were few discussions on hardwarization. Hardwrization is not a
protocol behaviour/characteristic. As such there is no reason to have
a requirement associated to that subject. However, we propose to add
the following text to Section 1.1.
    Note also that it is anticipated that implementers may wish to
    implement OAM message handling in hardware.  Although not a
    requirement, this fact could be taken as a design consideration.


========
Jonathan Sadler said:
>> Two key characteristics exist in this document that I don't see being
>> reflected in the OAM requirements draft:
>>
>> - A requirement for consistancy in OAM approach with other transport
>>   technology layers.
>>
>>   This characteristic is necessary to enable existing transport
>>   network management systems to easily integrate new transport
>>   technologies.  It further enables existing Methods and Procedures
>>   to be easily adapted for new technologies.

Please see Resolution 1.

>> - A requirement for OAM interactions between transport technology
>>   layers.
>>
>>   This characteristic is key when a network utilizes multiple
>>   transport technology layers to carry customer traffic.  This is
>>   very common in Transport networks. G.806 provides a framework for
>>   this interaction.  An example embodiment  can be found in G.782
>>   and its definition of OAM interactions between the RS and MS
>>   layers, as well as the MS and Path layers.  MPLS-TP is not an
>>   island of technology -- it runs over other transport layers (e.g.
>>   OTN/DWDM, Ethernet layers) and other transport layers are targeted
>>   to run on top of it (e.g. Ethernet over PseduoWire, SONET/SDH over
>>   PseudoWire).   The OAM mechanisms used in the layers found in
>>   Transport networks were developed with G.806 in mind.
>>   Interactions between the OAM indications from lower layers and
>>   MPLS-TP as well as between MPLS-TP and higher layers must be
>>   handled as described in G.806 when considering the design for
>>   MPLS-TP OAM.

We have a whole section on independence of OAM within TP, with TP
clients and with TP servers which says there can be interactions.


=========
Yoshinori Koike said:
>> Firstly, we would like to add one significant requirement which is
>> missing in the current draft. The proposed additional requirement in
>> section 2.2.2 "Scope of OAM" is as follows.

>>    It MUST be possible to operate the MPLS-TP OAM protocols, which
>>    satisfy functional requirements that are common to general
>>    transport layer network (i.e., independent of technology), in a
>>    way that is similar to other transport layer technologies which
>>    has been standardized and will be standardized in ITU-T (e.g.,
>>    SDH, OTN and Ethernet).

>> Second, most carriers are already familiar with existing transport
>> plane operational system. It would be very helpful to keep the
>> characteristic.

>> However, we also think it is also considerable to improve existing
>> transport network OAM, if they can be developed or advanced more
>> from the perspective of transport profile. We never mean to stop
>> further progress if the existing transport network OAM can be
>> further developed to more sophisticated one from the perspective of
>> transport profile.

Please see Resolution 1

>> Secondly, we attached "Proposal 1" as additional requirements
>> on the MPLS-TP OAM draft. We proposed several OAM requirements which
>> are not clarified in the MPLS-TP OAM requirement draft. We consider
>> that those items we proposed to make clear would be very beneficial
>> in terms of operational enhancement in packet transport network and
>> useful tool to operators using MPLS-TP technology in their commercial
>> network.

The document proposes 4 points
- Test function from MIP
I would like to stress that the OAM requirements does not use the notion
of MIPs and MEPs. These are defined in the OAM framework. By the way, I
guess you are referring to the Diagnostic functional requirement.
Nevertheless I would have liked to see this point more discussed before 
adding in the draft the capability of an intermediate point to inject
OAM.
- Status verification function of protection path
The OAM requirement does not make a distinction between working and
protecting. It is therefore possible to run OAM on a protecting e.g.,
LSP . In my view there is nothing to add.
- Flexible packet size
This was originally in the draft. I'll make sure it is properly
reflected.
- Bandwidth throughput verification
This is currently in the draft.

Please note that the Diag function is *not* the collection of
all the other functions in their on-demand mode.

>> Thirdly, we also attached "Proposal 2" as additional comments
>> on the MPLS-TP OAM draft. There are some ambiguities in existing
>> MPLS-TP OAM drafts. We believe this contribution will remove the
>> ambiguities and make existing MPLS-TP more productive.

This is valuable input. We believe it would well fit in the OAM framework.


=========
Resolution 1: Add the following text in Section 2.
   [RFC5654] requirement 2 states that the MPLS-TP design SHOULD as far
   as reasonably possible reuse existing MPLS standards. This general
   requirement applies to MPLS-TP OAM.
   MPLS-TP OAM is defined in this document through a set of functional
   requirements. These requirements will be met by protocol solutions
   defined in other documents. The way in which those protocols are
   operated and the way in which a network operator can control and use
   the MPLS-TP OAM functions SHOULD be as similar as possible to the
   mechanisms and techniques used to operate OAM in other transport
   technologies.

Resolution 2: Clarification of loopback

Diagnostic Tests
    The MPLS-TP OAM toolset MUST provide a function to enable conducting
    diagnostic tests on a PW, LSP or Section.  An example of such
    diagnostic test consists of performing a loop-back function at a node
    such that all OAM and data traffic are looped back to the originating
    End Point.  Another example of such diagnostic test consists in
    estimating the bandwidth of e.g., an LSP.
===========