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.
===========
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf