Progressing Work on P2mp MPLS-TP Connections

Progressing Work on P2mp MPLS-TP Connections

- 1 -

COM 15 – LS442 – E

/ INTERNATIONAL TELECOMMUNICATION UNION / COM 15 – LS442 – E
TELECOMMUNICATION
STANDARDIZATION SECTOR
STUDY PERIOD 2009-2012
English only
Original: English
Question(s): / 10, 12/15
LIAISON STATEMENT
Source: / ITU-T Study Group 15
Title: / Progressing work on p2mp MPLS-TP connections
LIAISON STATEMENT
For action to: / IETF MPLS WG
For comment to: / -
For information to: / -
Approval: / Agreed to at Study Group 15 meeting (Geneva, 10-21 September 2012)
Deadline: / 1 January 2013
Contact: / Huub van Helvoort (Q10/15)
Huawei Technologies Co. Ltd
P. R. China / Tel: +31 36 531 5076
Email:
Contact: / Malcolm Betts (Q12/15)
ZTE
P. R. China / Tel: +1 678 534-2542
Email:

Thank you for your liaison statement Response to LS 392 "Request advance work on the p2mp framework in MPLS-TP". We are pleased to note that you are progressing this work since some of the MPLS-TP work in SG15 is dependent on the RFCs that you plan to produce. Please keep us informed of your progress.

During our discussions we have identified a number of additional considerations:

  • The support of p2mp OAM on the data path should be independent of the availability of a return path or the mechanism that supports the return path:
  • The “return path” may be direct to the entity that originally requested the measurements (this may not be the head end of the p2mp connection):
  • Regarding configuration considerations, the following are additional requirements for unidirectional P2MP transport path in particular for the case where an out of band return path to the head end does not exist:
  • The EMS/NMS should provide a tool to manually configure consistent values of each piece of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) to a root-MEP and all the related leaf-MEPs in a MEG of a P2MP transport path.
  • Mismatches of configuration information (MEG-ID, MEP-ID, PHB for E-LSPs, transmission rate) between a root MEP and any leaf-MEP at which proactive monitoring is enabled, should be detected as a configuration mismatch alarm by parsing received CCCV OAM packets.
  • Mismatches of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) between a leaf MEP and any other leaf-MEP, at which proactive monitoring is enabled, may be detected through the configuration management process of EMS/NMS as a configuration mismatch alarm without receiving OAM packets from a source MEP.
  • The configuration information mismatch alarms described in 4 and 5 may be supported in the case in which proactive monitoring is not enabled in order to check those mismatches before monitoring functions are enabled.
  • The enabling or disabling of configuration mismatch alarms must be able to be configurable at each leaf-MEP independently.

______

ITU-T\COM-T\COM15\LS\442E.DOC

Top View