Subject: [mpls-tp] Few clarifications in the draft "draft-ietf-mpls-tp-linear-protection-02.txt"

From: Selvan <[email-masked]>
Date: Thu, 26 Aug 2010 18:17:12 +0530

Hi,

We require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02.txt". Kindly help us to understand
the below points:

1. DNR and NR is defined in *Sec 4.2.2 PSC Request field*, but not defined
the priority for these requests in *Sec 4.3.2 Priority of Inputs*. So please
clarify what is the priority for DNR

2. Handling of Remote DNR request when protection switching is in Normal
state is not stated in *Section 4.3.3.1 Normal State*. Please clarify what
should be the action when DNR request is received from the far end.

3. Clear and Clear Signal Fail is defined in *Sec 4.3.2* Priority of Inputs but
the code values are not defined anywhere in the document in order to compare
the clear and clear signal fail with other local requests.

Thanks

Selvan

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 29 Aug 2010 09:43:08 +0200

Selvan, hi

Thank you for your queries on the LP draft.

I will try to provide detailed replies inline - however as an
introduction to the replies I would like to point out that the draft
tries to differentiate between local inputs that are input to the Local
Request Logic (section 3.1.1) and the remote requests (section 3.1.2)
that are transmitted using the PSC format described in section 4.2 and
input directly into the PSC Process Logic (section 3.1.3).  For example,
NR & DNR are locally a result of processing the different local inputs
and the network configuration and these may be transmitted to the
far-end using a PSC message.  However, there is no NR or DNR local
input.

As a result of this logic -

1. There are no encodings for local inputs, e.g. Local SF, Local Clear,
Local Clear SF, in the PSC format (section 4.2.2) as these are not
received as PSC messages, but rather as local inputs or computation of
the total inputs and previous state (e.g. Local Clear SF is a result of
determining that there are no current local notifications and knowledge
that current state is Protecting Failure).

2. The priorities that appear in section 4.3.2 are priorities of the
local inputs (only) that should be used by the Local Request Logic to
determine the highest priority local request.  The remote requests are
not involved in this determination.

3. The computation by the PSC Process Logic is dependent upon three
"inputs" the highest priority local input, any remote request, and
knowledge of the current state of the PSC Process.  This determines the
next state of the process, any actions needed, and the remote PSC
message that should be sent to the far-end.

With this introduction, I hope that the answers below will be helpful,

yaacov

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Selvan
Sent: Thursday, August 26, 2010 15:47
To: [email-masked]
Subject: [mpls-tp] Few clarifications in the
draft"draft-ietf-mpls-tp-linear-protection-02.txt"

Hi,

We require few clarifications in the draft
"draft-ietf-mpls-tp-linear-protection-02.txt". Kindly help us to
understand the below points:

1. DNR and NR is defined in Sec 4.2.2 PSC Request field, but not defined
the priority for these requests in Sec 4.3.2 Priority of Inputs. So
please clarify what is the priority for DNR 

[yw>] DNR is only received as a remote message and therefore does not
have a local priority - that are described in section 4.3.2.
Essentially, DNR has no priority.

2. Handling of Remote DNR request when protection switching is in Normal
state is not stated in Section 4.3.3.1 Normal State. Please clarify what
should be the action when DNR request is received from the far end.

[yw>] There is a statement at the end of section 4.3.3.1 (and in fact
near the end of each of sections 4.3.3.x) "All other remote messages
SHOULD be ignored".  So if there is no explicit action described for DNR
then it should be ignored.

3. Clear and Clear Signal Fail is defined in Sec 4.3.2 Priority of
Inputs but the code values are not defined anywhere in the document in
order to compare the clear and clear signal fail with other local
requests.

[yw>] As pointed out above, the code values are only given for PSC
messages and their field values.  These two inputs are not received as
PSC messages and, therefore, have no code values, i.e. they are internal
to the PSC Control Logic.

Thanks

Selvan