[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: [mpls] working group last call on draft-ietf-mpls-tp-nm-req-01.txt
Kam, Scott, Eric, and all,
I have few LC comments on draft-ietf-mpls-tp-nm-req-01
General:
The separation between requirements of the MPLS-TP network elements
(NEs) and from the Network Management Entity is not always clear. It
would be useful to specifically note which requirements apply to NEs,
etc.
Section 4:
1. "Retrieval of DCN network parameters to ensure compatible
functioning, e.g. packet size, timeouts, quality of service, window
size, etc.; "
What is the usage of "retrieval" in this context. Shouldn't the function
support configuration of these parameters?
Section 5.1:
1. "The MPLS-TP NE MUST support supervision of the OAM mechanisms that
are deployed for supporting the OAM requirements defined in [3]."
The requirements are too general. It is not clear what the supervision
function should explicitly perform.
2. " . Supervision of looping check functions used to detect loops
in the data-plane forwarding path (which result in non-
delivery of traffic, wasting of forwarding resources and
unintended self-replication of traffic);
. Supervision of the detection of failure in the sequence of
a protocol exchange (e.g. automatic protection switching
protocol); "
Again, what is explicitly required from the supervision function?
Section 5.2:
1. "A Fault Cause indicates a limited interruption of the required
transport function."
There is no formal definition of Fault Cause. It would be useful to add
the definition of Fault Cause to section 1.1.
2. "The failure declaration and clearing MUST be time stamped. The
time-stamp SHALL indicate the time at which the fault cause is
activated at the input of the fault cause persistency (i.e.
defect-to-failure integration) function, and the time at which
the fault cause is deactivated at the input of the fault cause
persistency function. "
It is not clear who is the target of this requirement i.e. MPLS-TP NE or
a Management System Entity?
Section 5.3.2: "An MPLS-TP NE MUST provide alarm suppression
functionality that prevents the generation of superfluous alarms. "
It would probably be better to note that alarms resulting from other
alarms should be suppressed instead of "superfluous alarms".
Section 5.3.3: "Alarm Reporting Control (ARC) supports an automatic
in-service provisioning capability. "
1. Would be useful to define the functionality of the ARC
2. Would be useful to define what exactly is required by "automatic
in-service provisioning".
Section 6.5: " The MPLS-TP NE MUST have the flexibility to configure
OAM parameters to meet their specific operational requirements, such
as whether (1) one-time on-demand immediately or (2)
one-time on-demand pre-scheduled or (3) on-demand periodically based on
a
specified schedule or (4) proactive on-going. "
1. It may be more appropriate to use the term "capability" instead of
"flexibility".
Thank you,
Yoav Cohen.
-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
ext Loa Andersson
Sent: Monday, May 04, 2009 18:25
To: mpls-tp at ietf.org; mpls at ietf.org; ccamp at ops.ietf.org; pwe3 at ietf.org;
l2vpn at ietf.org; Adrian Farrel; Ross Callon; George Swallow
Subject: [mpls] working group last call on
draft-ietf-mpls-tp-nm-req-01.txt
ALL,
This is to start a two week working group last call on
draft-ietf-mpls-tp-nm-req-01.txt
Please send your comments to the mpls-tp mailing list.
This working group last call is joint between the mpls, ccamp. Pwe3 and
l2vpn.
The working group lst call ends on May 19th eob.
/Loa
--
Loa Andersson
Sr Strategy and Standards Manager phone: +46 10 717 52 13
Ericsson /// +46 767 72 92 13
email:
loa.andersson at ericsson.com
loa.andersson at redback.com
loa at pi.nu
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls