Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard
Yaacov Weingarten <wyaacov@gmail.com> Wed, 26 March 2014 21:08 UTC
Return-Path: <wyaacov@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61C1A03CC; Wed, 26 Mar 2014 14:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 IrFO9Gk7gQsK; Wed, 26 Mar 2014 14:08:39 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48E1A0220; Wed, 26 Mar 2014 14:08:39 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id i50so1630880qgf.28 for <multiple recipients>; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qep14cLXBpjnq7wlNQkWau72Ysy1lHS2JTdCmujAhSw=; b=A7gRyvH4EMXvRZilmALxIOSWN8HkfDD0WDRR6yRRKVx0ptrYM1tuWmsgoY1y7VJ5X3 yZ8mw75CllYi1rLOJ+FEFjIm5cRJl6irDHZBGbmVX0G0xdopEufJ6RF+Nj96UziBDBK1 jmJnA7cKx9kkjjx8okO4xD0BmZ/JzSrCs5pzmeTSN6GWmwaQe8UG3Mq/Nh6bM1z2MIAO P083vYuwJSY62V3ttpLJV9faWfHNxZ9ReUuvuCI4VynUMGED67isBRQ2sMzyYtkkvq/H ydwO+c8zDtmAL0sNnQEsWAf3DJRwQ6gqJwP2cn3ceS/zGqLgm/EwiEEvm/ejzqbnSVrO me5A==
MIME-Version: 1.0
X-Received: by 10.224.75.5 with SMTP id w5mr32527594qaj.52.1395868117663; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
Received: by 10.224.173.2 with HTTP; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
In-Reply-To: <20140326195717.26906.70350.idtracker@ietfa.amsl.com>
References: <20140326195717.26906.70350.idtracker@ietfa.amsl.com>
Date: Wed, 26 Mar 2014 23:08:37 +0200
Message-ID: <CAM0WBXWAm8mAAAXKxNaCi+x3O7hfPr_U5_bcvzWZKYExCUSiAA@mail.gmail.com>
From: Yaacov Weingarten <wyaacov@gmail.com>
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary="001a11c357c24e84d804f588df64"
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LZMe2z3eGladQ4i2bw-uacy6AkU
Cc: mpls@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 26 Mar 2014 21:08:43 -0000
Hi, Some comments and nits regarding this draft: 1. The Abstract states "This document contains four updates to", whereas the first statement of the Introduction states "This document contains firve updates to" - so aside from the spelling mistake please align the two statements to the correct number of updates. 2. Section 5 is very confusing to me - a. My understanding was that the PSC Control Logic always receives two inputs - one local and one remote and decides on the the next state based upon these two inputs and the current state of the Control Logic as defined in the FSM. You, however, state that you need to explain how the Control Logic should react to different inputs. After explaining, the two cases of different inputs, you then state that the reaction to these inputs is already covered in RFC6378, and what needs to be clarified is the recovery from the input that was defining the current state! Not sure what you really meant to say, but it would help if you gave a consistent message throughout as to what needs to be clarified! b. At some point you state that the Control Logic should remember the last received local and remote inputs for reevaluation when the driving input is cleared. But then you go and prove that this is not necessarily true, since the inputs may change during the interim (went from R(LO) to R(SF-W)). Therefore, I think that the correct interpretation should be based on the two current inputs as provided by the Local Request Logic and Remote Input. What may need to be corrected is that each of these two units should persist their latest outputs to continue to be provided as input to the Control Logic. c. Your first example, (in the third paragraph) describes two FS inputs (a "local" and "remove" [should be changed to "remote"]) to the Control Logic, but then in the fifth paragraph it is a "local SF" that is driving the state. Please change this to "local FS". Hope these help, yaacov On Wed, Mar 26, 2014 at 9:57 PM, The IESG <iesg-secretary@ietf.org> wrote: > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Updates to MPLS Transport Profile Linear Protection' > <draft-ietf-mpls-psc-updates-03.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-04-09. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > This document contains four updates to the Protection State > Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile > (MPLS-TP) Linear Protection" . Two of the updates correct existing > behavior. The third clarifies a behavior which was not explained in > the RFC, and the fourth adds rules around handling capabilities > mismatches. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ballot/ > > No IPR declarations have been submitted directly on this I-D. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity*
- [mpls] Last Call: <draft-ietf-mpls-psc-updates-03… The IESG
- Re: [mpls] Last Call: <draft-ietf-mpls-psc-update… Adrian Farrel
- Re: [mpls] Last Call: <draft-ietf-mpls-psc-update… Yaacov Weingarten
- Re: [mpls] Last Call: <draft-ietf-mpls-psc-update… Eric Osborne
- Re: [mpls] Last Call: <draft-ietf-mpls-psc-update… Eric Osborne
- Re: [mpls] Last Call: <draft-ietf-mpls-psc-update… Adrian Farrel