The MPLS WG Archive

[Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>]

Scott and all,

The following text has been prepared by the email discussion group of
ITU-T SG13/Q3 in response to IETF's request for explanation of the
long-term implications of Y.1711 on IETF protocols.  I post it on behalf
of the group because I think it is useful to know your views on this
response before ITU-T SG13/Q3 drafts an official response.  Based on
this text, an official response from ITU-T SG13/Question 3 will be
prepared at the next Q3 meeting to be held 3-5 July 2002 in Chitose, Japan.

Hiroshi

***************************************************

Summary:

Y.1711 depends on the reserved MPLS label (14) in order to operate, and
this was the only method that did not raise any objections when discussed
on the MPLS list over a year ago. Any other extension to IETF protocols is
purely optional and not essential for the operation of Y.1711 and require
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.

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. If for example a Network processor has been used for
the MPLS forwarding plane, Y.1711 could easily be implemented by a 
firmware/software
upgrade. Even in case the MPLS forwarding plane is implemented in ASICs, if 
the
ASIC has the capability to extract/inject MPLS packets with the reserved 
labels,
then the Y.1711 functionality could be supported by upgrade of existing 
firmware/software.

*************************************************



At 14:52 02/04/29 -0400, Scott  Bradner wrote:

>after reviewing the discussion on the draft response to SG 13 about
>draft-ohta-mpls-label-value-01.txt - I simplified the letter and just sent
>the following to  Brian Moore (SG 13 chair)
>
>Scott
>
>------------------
>SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director
>
>TITLE: Response to "Communication on the status of the request on the 
>assignment of
>a reserved label value for MPLS OAM packet identification"
>
>The MPLS working group discussed SG 13's request for the assignment of a 
>reserved
>label value for MPLS OAM packet identification 
>(draft-ohta-mpls-label-value-01.txt)
>during the MPLS session during the recent IETF meeting in 
>Minneapolis.  There was
>some disagreement during the discussion about the long term 
>implications  of the
>IETF granting this request.
>
>During the discussion it was noted that there are a number of references 
>to what
>might be modifications to IETF protocols in Y.1711.  For example, Section 6.1
>states, "Ideally this should be done automatically  via LSP signaling at 
>LSP set-up
>time (e.g. via a CR-LDP or RSVP  control-plane mechanism), but it could 
>also be
>configured manually."
>
>In order to understand the possible consequences of allocating an MPLS 
>codepoint in
>response to the request in draft-ohta-mpls-label-value-01.txt the MPLS 
>working group
>would like to understand the what modifications that SG13 may be assuming 
>will be
>needed to other IETF protocols.  (LDP, CR-LDP, RSVP, PIM and BGP have been 
>suggested
>as IETF protocols that might be impacted.)
>
>A further concern is the potential impact on the MPLS forwarding plane as 
>currently
>defined.  In certain points in a MPLS network, based on an incoming label, 
>the label
>is removed and the packet is forwarded with no further inspection of 
>subsequent
>headers (be it another MPLS label or some other header). Y.1711 seems to 
>imply that
>the above behavior would not satisfy Y.1711. Specifically, there are some 
>cases
>where Y.1711 would expect a network element to intercept an OAM 
>packet.   Thus, the
>MPLS working group would like to understand if SG 13 thinks that Y.1711 
>assumes
>functionally that might raise issues of backward compatibility with 
>existing MPLS
>systems and ASICs.