Subject: RE: Questions about Y.1711

From: "Qureshi, Muhammad A (Akber)" <[email-masked]>
Date: Tue, 19 Aug 2003 10:57:39 -0400

Hi Defeng,

Please see my comments inline;

Regards,
Akber.

-----Original Message-----
From: lidefeng [mailto:[email-masked]]
Sent: Tuesday, August 19, 2003 5:52 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Questions about Y.1711

Dear Sir,

In section 6 of Y.1711,the OAM mechanisms are specified,however,I have some
questions about them,could you please clarify them?

1. In section 6.1.1 Stack encoding,it states that "OAM packets are
differentiated from normal user-plane traffic by an increase of one in the
label stack depth at a given LSP level at which they are inserted.
Therefore, they maintain this label stack difference of one (from normal
user-plane traffic) as they traverse any lower layer server LSPs." Do you
mean that the OAM Alert labelled header is inserted between the normal
user-plane forwarding label and the CV payload(or FFD payload),e.g. The
structure of an CV OAM frame is as follows:

____________________________________________________________________________
__________
|L2 Frame Header | User-plane |  OAM Alert | Function | Reserved |LSP Trail
Termination | Padding | BIP16|
|__Header______  |_Label___  |__Label___  |_Type__  |______ _  |___Source
Identifier_  |______   |_____ |

Do you think if I catch it?
[Akber]Yes.

2. If OAM Alert Label is the bottom of the label stack,then the OAM Alert
Label is only processed by the Egress LSR, i.e.OAM packets are transparent
to intermediate LSRs, including the penultimate LSR,then what if the defect
is happened in the intermediate LSR,then the OAM packets can't reach the
Egress LSR,how can the OAM function be implemented? and how can this defect
be detected?
[Akber] The egress LSR monitors for arrival of connectivity verification (CV)
OAM packets. It is expecting to see CV packets for each terminating LSP. If due
to a problem in an intermediate LSR, it does not observe CV packets for a 
particular LSP then it knows that there is some problem with the LSP. (In this
case, the defect type can be simply dLOCV (loss-of-connectivity) or dTTSI_mismatch
(mis-configuration)). There are other defect types.
[Akber] This does not tell that which intermediate LSR has the problem.
I believe fault localization is not within the scope of this recommendation.

3.In the Payload of FDI and BDI,the "Defect Location" field is formed by AS
number,then the defect location can only be in granularity of AS,then how
can the defect in the particular LSR of the defected AS be loacted? An AS is
composed of many LSR,how can operator find out which LSR is doing wrong?
Furthermore,a LSP is normally setup in a single AS,what is the significance
to find out th AS number of the defected LSP?
[Akber] An AS number is only there to indicate that in which domain the
problem is observed and can be useful in case of multiple domains.

4.A return LSP is important for BDI OAM packet,could you please how to setup
the return LSP or select the return LSP from the existed LSP?
[Akber] I believe that this is not within the scope of this recommendation.

5.Could you please tell me which vender has implemented the MPLS OAM
function,and how about the interoperability test?

TIA & Best Regards

Sincerely Yours

Defeng Li
Huawei Technologies
+86-10-82882343
[email-masked]