Subject: Re: [mpls-tp] working group last call on draft-ietf-mpls-tp-nm-req-01.txt

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 May 2009 17:08:55 +0300

Hi all,
I am reading draft-ietf-mpls-tp-nm-req-01.txt and I'd like to offer several comments:

 1.  Section 4 of the draft deals with the MCN requirements. However, it seems that requirements for the MSN survivability are not mentioned in this section (or anywhere else in the draft).
    *   From my experience (which may be outdated), operators usually treat loss of management communication with a Managed Element as a critical problem
    *   Based on this, the requirement to be able to manage an MPLS-TP device as long as it conveys traffic does not look as an exaggeration to me. (Note that this requirement is automatically met with IP/MPLS networks)
    *   At the same time, there is probably no need to provide the same restoration times for management communication as for the customer traffic
 2.  Section 5.5.2 deals with alarm suppression and defined a MUST requirement to suppress "superfluous alarms". However, the notion of the superfluous alarm" is not defined (neither directly in the draft nor by reference to other sources). Taking into account that there are more than 50 messages discussing AIS/FDI on this list, it seems that the superfluosity of an alarm is in the eye of the beholder...
 3.  Section 6.3 contains a requirement to be able to configure "an LSP identifier and/or other information necessary to retrieve the LSP status information":
    *   It seems that an "LSP identifier" is not defined in the draft (directly or by reference)
    *   Blanket requirements "other information necessary to..." look somewhat problematic to me
    *   Note also that this seems to be the only requirement related to LSP configuration, i.e., the only thing that is required to be configured is LSP identifier while ability to configure the LSP itself seems to be not important.
 4.  Requirements in section 6.4 seem to completely skip the need to configure "facility backup" mechanisms since they speak about ability to identify an LSP as working or protection... Note that if SONET/SDH networks were managed like that, it would mean that ability to configure BLSR/MSP-Ring mechanisms would not be required...
 5.  One of the requirements in Section 6.5 mentions configuration of "MEP ID and MIP ID":
    *   Neither is explicitly defined
    *   Looking at IEEE 802.3ag-2007 (Section 19.3.1) as the presumably suitable reference, I see that MEP IDs are defined there, but MIP IDs are not.
 6.  Last but not least, the ultimate goal of standardization is to facilitate interoperability of devices from multiple vendors. IMHO and FWIW, when it comes to network management, this is translated into a requirement to expose a suitable generic information model to the NMS. I have not found any such requirement in the draft.

My 2c,
     Sasha

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 13 May 2009 15:37:41 +0200

On behalf of Yoav to the MPLS-TP group......

-----Original Message-----
From: Cohen, Yoav (NSN - IL/Hod HaSharon) 
Sent: Wednesday, May 13, 2009 3:25 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: 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: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Loa Andersson
Sent: Monday, May 04, 2009 18:25
To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; 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:
[email-masked]
                                               [email-masked]
                                               [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: yuliang <[email-masked]>
Date: Wed, 20 May 2009 11:01:28 +0800

Hi Colleagues,
My comments on draft-ietf-mpls-tp-nm-req-01.txt
1)  section 3      
       An MPLS-TP management network SHOULD support seamless management
        connectivity with remote MPLS-TP domains and NEs as well as with
        termination points located in NEs under control by a third party
        network operator.  See ITU-T G.8601 [8] for example scenarios in
        multi-carrier multi-transport-technology environments
[YL]  what's the "seamless management connectivity" mean? I guess you wanna
say: there are some scenarios that between MPLS-TP management network and
the MPLS-TP NEs ,there may be a network who cannot support MPLS-TP MCC, but
we still require the management network to connect & manage the MPLS-TP NEs,
am I right?

2)   section 3
       For management purpose, every MPLS-TP NE MUST connect to an OS
        either directly or indirectly via another MPLS-TP NE. When an
        MPLS-TP NE is connected indirectly to an OS, an MCC MUST be
        supported between the MPLS-TP NE and the other MPLS-TP NE.
[YL] Why MPLS-TP NE 'MUST' connect to an OS either directly or indirectly
via another 'MPLS-TP NE'? As well as via a 'IP/MPLS NE' is OK?

3) section 6 Path Configuration
        The MPLS-TP NE MUST support the capability of configuring
        required LSPs as follows:
            . configure LSP indentifier and/or other information
               necessary to retrieve LSP status information.
[YL] This section is about 'Path Configuration', but there is no word about
require setup, modify... a path. So, do we just use control plane to setup a
LSP, and after that, "configure LSP indentifier and/or other information
necessary to retrieve LSP status information." via management plane? 
And, what "LSP indentifier" and "other information necessary" stand for? I'm
afraid you should have an explicit definition of it.

4)  6.4. Protection Configuration
This part said more about end-to-end LSP protection configuration, but what
about protection configuration of segment LSP & section?