[mpls] Text proposal on draft-ietf-mpls-tp-aps-updates

"Ryoo, Jeong-dong " <ryoo@etri.re.kr> Sun, 28 August 2016 10:54 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2FB12D19F; Sun, 28 Aug 2016 03:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level:
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBIuqCkKrKhr; Sun, 28 Aug 2016 03:54:39 -0700 (PDT)
Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1457712D1B7; Sun, 28 Aug 2016 03:54:36 -0700 (PDT)
Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 28 Aug 2016 19:54:32 +0900
Received: from SMTP2.etri.info ([169.254.2.208]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Sun, 28 Aug 2016 19:54:31 +0900
From: "Ryoo, Jeong-dong " <ryoo@etri.re.kr>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Text proposal on draft-ietf-mpls-tp-aps-updates
Thread-Index: AdIBGo2gkC393KBrS1q/KfR+z4PAYw==
Date: Sun, 28 Aug 2016 10:54:30 +0000
Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2920D092@SMTP2.etri.info>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-new-displayname: UnlvbywgSmVvbmctZG9uZyA=
x-originating-ip: [129.254.28.42]
Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2920D092SMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/b2A8NfhRlGbigs6nYUO0rdXxHqo>
Cc: "draft-ietf-mpls-tp-aps-updates.chairs@ietf.org" <draft-ietf-mpls-tp-aps-updates.chairs@ietf.org>
Subject: [mpls] Text proposal on draft-ietf-mpls-tp-aps-updates
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Aug 2016 10:54:42 -0000

 Hi, all.


As presented in the last MPLS WG session in Berlin,
the authors of draft-ietf-mpls-tp-aps-updates would like to

add some text to the next version.


There are two issues that we want to address in the revision.


Issue #1. According to RFC 7271,

in the event of SFDc (Clear Signal Fail or Degrade),
all the local and remote requests are re-evaluated
as if the node is in Normal (or DNR) state.
However, in case of clearance of local SF-P,
the last received remote message may not be valid any more
due to the previous failure of the protection path,
and it should not be considered as an input to the priority evaluation.


Issue #2. According to RFC 7271, the letter ‘i’ in the state transition tables
stands for “ignore” and is an indication to remain in the current state
and continue transmitting the current PSC message.
In this statement, we assume that what is being ignored is
the top-priority global request, which was a trigger for a new state transition.
A potential ambiguity arises when all the local and remote requests
are re-evaluated after OC or SFDc.
For example, if local EXER is cleared in E::L state,
according to note (5), re-evaluation is performed to determine
the final state as if the node is in the Normal (or DNR) state
depending on the value of Path field.
In this case, the remote message is RR, and the RR message

will be “ignored” according to the state transition table.
Then, the final state should be Normal (or DNR) state.
But, if one may misinterpret “i” as remaining in the current state,
which is E::L, then the local EXER will never be cleared.


In order to address the above two issues,
we propose to add a new subsection (4.3) and the following text

 to the current draft:


%%% Beginning of Text Proposal %%%


4.3.   Operation related to State Transition Table Lookup


In addition to the rules related to the state transition table
lookup listed in Section 11 of [RFC7271], the following rule is
also applied to the operation related to the state transition
table lookup:

  O When the local SF-P is cleared and the priorities of the
    local and remote requests are re-evaluated,
    the last received remote message may not be valid any more
    due to the previous failure of the protection path and only
    the local request SHALL be evaluated assuming that the
    remote request is NR.


The last paragraph in Section 11 of [RFC7271] is modified as
follows:
---------
Old text:
---------
In the state transition tables below, the letter 'i' stands for
"ignore" and is an indication to remain in the current state and
continue transmitting the current PSC message.
----------
New text:
----------
In the state transition tables below, the letter 'i' stands for
"ignore" and the top-priority global request is ignored.
Therefore, the next state can be either the current state
transmitting the current PSC message or the supposed state
(Normal or DNR depending on the footnotes to the state transition
tables) in case of re-evaluation.

%%% End of Text Proposal %%%


We would like to have your comments on the issues and text proposal.


Best regards,



Jeong-dong
(On behalf of authors)