ITU - Telecommunication Standardization Sector 8 July 2002 QUESTIONS: 3/13 SOURCE: ITU-T Working Party 3/13 meeting (Chitose, Japan, 8 July 2002) TITLE: Response to Communication from IETF on MPLS OAM packet identification _____________ LIAISON STATEMENT TO: IETF Sub-IP Area (Scott Bradner, Area Co-Director) APPROVAL: Agreed to at WP 3/13 meeting FOR: Action DEADLINE: 31 August 2002 CONTACT: Hiroshi Ohta Tel: +81 422 59 3617 NTT Fax: +81 422 59 3787 3-9-11 Midori-cho Musashino-shi Email: ohta.hiroshi@lab.ntt.co.jp Tokyo 180-8585 Japan This liaison statement is prepared to respond to the Communication from IETF Sub-IP Area (Scott Bradner, Area Co-Director) titled "Response to "Communication on the status of the request on the assignment of a reserved label value for MPLS OAM packet identification". Summary: Any extension to IETF protocols other than the assignment of the reserved label value of 14 for OAM packet identification is purely optional and not essential for the operation of Y.1711 and requires further technical study as well as usability assessment. In any case such extensions are not targeted to the current revision of the Y.1711. Details: The MPLS OAM, as defined in Y.1711, has the following requirements: 1) Identification of OAM packets: A reserved MPLS label (suggested label=14) is REQUIRED for the identification of OAM packets. Without this reserved Label, it is not possible to implement Y.1711. Note that this was discussed on the MPLS list over a year ago and the consensus for OAM packet identification was to use a globally reserved label. 2) Activation/Set up of the Connectivity Verification (CV) processing: Running and monitoring the CV flow on any specific LSP is optional in Y.1711. Since the CV processing is done at the egress LSR, it needs to know whether to look for CV packets on a specific LSP or not. On the other hand there are a number of different CV processing options that may be done at an egress LSR (see appendix I of Y.1711). Currently Y.1711 relies on manual configuration of the egress LSR for setting up the CV processing function. Manual configuration of the egress LSR is currently sufficient for the current version of Y.1711. In future it may be desired to use signaling methods to setup the CV processing at an egress LSR for a specific LSP. The key point here is that OAM activation/deactivation needs to be harmonized with any control-plane set-up/tear-down of LSPs, e.g. to stop OAM processing, and hence consequent action such as alarm generation, when an LSP is consciously removed. The methods to achieve this could be: a) OPTIONAL extension to RSVP-TE and CR-LDP. b) Defining new setup OAM packets using the OAM reserved label (14) c) Configuration via NMS. 3) Knowledge of Server-Client relationship: For the purpose of suppressing down-stream alarms, the FDI (Forward Defect Identifier) must be mapped from a lower layer LSP to a higher layer LSP at the egress LSR. Therefore the egress LSR needs to know which LSPs are tunneled inside a specific LSP. Currently Y.1711 relies on two possible methods for setting up the client-server relationship between LSPs: a) Manual configuration of the egress LSR b) Automatic learning process: If during the establishment of the client LSPs, the signaling is tunneled through the server LSP, then the server trail terminating node (egress) could keep the information about the client LSPs in memory as they occur. In future it may be desired to use signaling methods to setup the Server-Client relationship for a specific LSP. The methods to achieve this could be: c) OPTIONAL extension to RSVP-TE and CR-LDP. d) Defining new setup OAM packets using the OAM reserved label (14) e) Configuration via NMS. Other functions such as Performance (P) flows, loop-back, trace-route, variable CV rate, etc are under study and we can't comment on their requirements at this time. It is also far from certain that all these functions would ever be adopted in any case....this will depend on contributions, especially from operators requesting the development of such functions. Following are ITU's answers to the specific issues raised in your liaison: A) Section 6.1 issue: The egress LSR needs to know the TTSI for a terminating LSP. According to Y.1711, TTSI = Router_ID + LSP_ID. Both the Router_ID and LSP_ID are already signaled in the existing RSVP-TE and CR-LDP protocols in the form of Session Object and LSPID TLV respectively. Therefore there is no need for further extensions to these protocols to signal the TTSI. B) Impact on IETF protocols: We don't foresee any changes to any other IETF protocol except those noted in this correspondence. Specifically we don't foresee any changes required to BGP and PIM. C) Impact on forwarding plane: There is no requirement in Y.1711 to intercept OAM packets or to inspect subsequent header/label when it should not (such as in PHP case). We feel sure that Y.1711 is fully backward compatible with all MPLS standards. D) There is a requirement in Y.1711 to inject an OAM packet (i.e., FDI packet) in the middle of an LSP. However, this should be possible by software upgrade in LSR as is done in Section 2.3.2 of RFC3032 in which an LSR injects an ICMP packet in the middle of an LSP. E) Impact on current systems and ASICs: Y.1711 recommendation has been developed based on input from various leading vendors. Whether it is possible to implement Y.1711 in the current systems and ASICs depends on the specific vendor's implementation. In general, MPLS forwarding devices can inject IP packets. Therefore, it should be possible to inject non-IP packets by software change. Since Y.1711 permits running CV on selected LSPs, overloading of processor can be avoided by reducing the number of LSPs with CV activated. Attachments: Draft Rec. Y.1710/Cor. 1, draft Rec. Y.1711 and draft Rec. Y.1720 may be reviewed at http://www.itu.int/ITU-T/studygroups/com13/ip/sg13-ietf-ftp.html.