Subject: [mpls-tp] WG-LC comments on OAM Requirements document

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 16 Jul 2009 16:31:13 +0200

I have the following comments on draft-ietf-mpls-tp-oam-requirements-02:

Section 2.1.3:
The term "forwarding plane" is used in the first bullet item and the
term "user plane" in the second. Both are not defined in the document. I
suggest to replace both with "data plane" which is defined in 2.1.5.
Furthermore it is not clear to me what "it MUST be possible to operate
the OAM functions by relying on IP routing and forwarding capabilities"
means:
- Is it about the configuration, activation, deactivation of OAM
functions as the term "operate" may suggest or is it about the OAM
function itself?
- In the first case it is a management plane feature and the IP
forwarding should be related to the management plane
- In the second case "rely on" would mean that it must be possible to
make us of IP forwarding in the OAM functions. However even in an
environment with IP routing and forwarding the MPLS_TP packets are still
forwarded based on their labels I assume and the OAM packets which share
the fade will use the same forwarding and not IP forwarding. Please
clarify, for example does GACH-GAL based OAM comply to this requirement
and how? My proposal for a modified sentence is  "In this case, it MUST
be possible to operate the OAM functions in  the presence of IP routing
and forwarding capabilities.".

Section 2.2.6
>From the text it is not clear if in case of bi-directional PW, LSP or
section always both directions are locked or if individual directions
can be locked. Please clarify.

Section 2.2.7
The term "external lock condition" is not clear. I assume it is a lock
condition of server layers that support the link connection from the
adjacent point to this point.
Furthermore not only intermediate points have to inform the end points,
end points also have to be aware of lock conditions of server layers
that support the link connection to this end point.
Suggested modification:   
"The MPLS-TP OAM toolset MUST provide functionality to enable an
Intermediate Point of a PW or LSP to report, to an End Point of that
same PW or LSP, a server layer lock condition affecting the link
connection from an adjacent point to this intermediate point. 
The MPLS-TP OAM toolset MUST provide functionality to enable an End
Point of a PW or LSP to be aware of a server layer lock condition
affecting the link connection from an adjacent point to this end point."

Section 2.2.8
The term" fault and defect condition affecting that PW or LSP" is not
clear. I assume defect conditions of the server layer are meant. A fault
of the local forwarding in the LSR will also affect the PW, LSP however
this will be detected at the end point of the PW; LSP and not reported
from the intermediate point. Furthermore not only intermediate points
have to inform the end points, end points also have to be aware
fault/defect conditions of server layers that support the link
connection to this end point.
Suggested modification:   
"The MPLS-TP OAM toolset MUST provide functionality to enable an
Intermediate Point of a PW or LSP to report, to an End Point of that
same PW or LSP, a fault or defect condition of a server layer affecting
the link connection from an adjacent point to this intermediate point.
The MPLS-TP OAM toolset MUST provide functionality to enable an End
Point of a PW or LSP to be aware of a fault or defect condition of a
server layer affecting the link connection from an adjacent point to
this end point."

Section 2.2.10
"client defect of fault condition" should be "client defect or fault
condition"
In order to clarify that the reporting is only from ingress to egress
end point a addition to "End Point" is proposed:
   "The MPLS-TP OAM toolset MUST provide functionality to enable the
   propagation, across an MPLS-TP network, of information pertaining to
   a client defect of fault condition detected at an ingress End Point
of a PW
   or LSP, if the client layer OAM mechanisms do not provide an alarm
   notification/propagation mechanism."

Section 2.2.11 and 2.2.12
The term "user-plane traffic" is used in the last paragraph. In other
locations of the document "user traffic" is used. Therefore I suggest to
use "user traffic" also for these two paragraphs.

Regards

Juergen

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:23:42 +0200

Hi Juergen,

thanks for your review,
please see in-line.

regards,
martin

> suggest to replace both with "data plane" which is defined in 2.1.5.

point already raised. Will clarify. "Data plane" could indeed be used.
> and forwarding capabilities.".

In IP/MPLS/PWE, certain mechanisms rely on the encapsulation in an IP
header to identify and process OAM messages.
In IP enabled environments it MUST be possible to rely on same/similar
mechanisms to operate the OAM protocols that will meet the functional
requirements this draft lists.
However this draft recognizes that there are environments where such
mechanisms are not possible and therefore requires that it be also
possible to operate the OAM protocols that will meet the functional
requirements this draft lists.
RFC 5886 defines a mechanism that meets this latter requirement.
Hope it clarifies.
> can be locked. Please clarify.

I would say that, as it is, the requirement would allow a protocol
solution to do both:
- lock a single direction
- lock both
> adjacent point to this point.

it is indeed a possible interpretation of "external".
> that support the link connection to this end point.

True, but if client and server end-points are collocated,
then "end-point to end-point" information exchange is system
internal and therefore outside the scope of the document.
> connection to this end point.

the failure is also "external". I will clarify.
See my comment above concerning your "end point" related suggestion.
> "client defect of fault condition" should be "client defect or fault 

indeed
>    notification/propagation mechanism."

I am not sure this achieves your objective while I believe the
following sentence does, doesn't it?
   "This function SHOULD be performed between End Points of PWs, LSPs and
    Sections."
> use "user traffic" also for these two paragraphs.

thanks. I'll make sure the use of these terms is consistent throughout
the document
> 
> Regards
> 
> Juergen
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp