Subject: message #2 from ITU-T SG 13

From: Scott Bradner <[email-masked]>
Date: Thu, 11 Jul 2002 08:02:49 -0400 (EDT)

TU - 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	
		Tokyo 180-8585 Japan
		Email: [email-masked]

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.