Re: [Mpls-review] MPLS-RT review ofdraft-ezy-mpls-tp-1ton-protection-00.txt

<> Tue, 10 July 2012 11:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D8DC21F8781 for <>; Tue, 10 Jul 2012 04:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.09
X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p2R+DRkQH+oQ for <>; Tue, 10 Jul 2012 04:46:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE3E821F8780 for <>; Tue, 10 Jul 2012 04:46:37 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 64EA337C86; Tue, 10 Jul 2012 20:47:04 +0900 (JST)
Received: from by (8.13.1/8.13.1) id q6ABl4tN031846; Tue, 10 Jul 2012 20:47:04 +0900
Received: from (localhost.localdomain []) by (Switch-3.3.4/Switch-3.3.4) with ESMTP id q6ABl0vl010025; Tue, 10 Jul 2012 20:47:04 +0900
Received: from ([ []]) by with RELAY id q6ABl3bU010033 ; Tue, 10 Jul 2012 20:47:04 +0900
X-AuditID: b753bd60-996f1ba000000f6c-93-4ffc16368d0d
Received: from (unknown []) by (Symantec Mail Security) with ESMTP id D21958B038F; Tue, 10 Jul 2012 20:47:02 +0900 (JST)
Received: from [] by (AIX5.2/8.11.6p2/8.11.0) id q6ABl2C27402294; Tue, 10 Jul 2012 20:47:02 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM1$6$0$0$$9$1$2$A$>
Content-Type: text/plain; charset=ISO-2022-JP
To: <>, <>, <>
From: <>
Date: Tue, 10 Jul 2012 20:46:48 +0900
Priority: normal
Importance: normal
X400-Content-Identifier: X4FFC161E00000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28120710204638GRD]
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Mpls-review] MPLS-RT review ofdraft-ezy-mpls-tp-1ton-protection-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MPLS Review <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2012 11:46:38 -0000

Dear, all.

I've reviewed draft-ezy-mpls-tp-1ton-protection-00.txt.
1:n protection is described in RFC6372(Survivability framework), and this is 
a good starting point. So I agree to WG adoption of draft-ezy.
The followings are my comments for clarification. Please consider them.
Let me start with my comment on WFA in Non-Locking mode. 
Does "persistent disagreement" in section 4.3.5. mean no ACK reply, 
or race condition? I'd like to know why the state machine behavior is different 
from that of RFC6378, which doesn’t have WFA state.  If there's already the 
answer in this draft, please let me know.

My next concern is that there seems no interoperability between draft-ezy and 
RFC6378, since the version numbers are different. It would be valuable if 
there is interoperability when n=1 in Non-Locking mode. 

Next comment is about WFA in Locking mode. 
I propose values of B and S of LER-Z in WFA (t3, t4) in Fig.9 be coordinated 
to make the behavior simpler. And in my understanding, B value should always 
be coordinated with data path field, so 'B' could be cut off to make the 
description simpler. In addition, I suppose Fig.3 description need to be 
corrected. "SF(1,1)" in the event description at t1 might be "SF(1, 0)", 
and "B=1" of LER-A at t2 might be "B=n/a".

And the followings are minor comments. 
- According to section 1.4, there seems no equal priority LSPs. 
  Is this the result of ML discussion during IETF 83 meeting, or are you 
  planning to update it?
- In Section 3.1 and 3.2, it would be helpful to specify the layer of label
  (LSP or PW), and align the expressions between these sections. For example 
  so far, W1 is path(LSP) in 3.1, while W1 is interface in 3.2.
- Is Section 4.3.2. tile "two-phased" based on general definition? This is just 
  a confirmation, since non-locking mode seems to be "single-phased" to me.
- The description in Section 4.3.3., "before performing a protection switch the 
  endpoint that detected a switching trigger MUST wait for an Acknowledge message 
  prior to performing the switch” should be limited only to Locking-mode.
- I expect L-flag value for non-locking mode will be specified in section 4.2.1. 
  by future draft update.
- I expect WFA timer range and default value will be specified in section 4.3.4. 
  by future draft update.
- Section 3.3.2. typo: s/"ir has been noticed it at the near endpoint."/"it has been noticed at the near endpoint."

Best Regards,

>Kenji, Thomas and David,
>you have been selected to do the MPLS-RT review of
>Reviews should comment on whether the document is coherent, is it useful
>(ie, is it likely to be actually useful in operational networks), and is
>the document technically sound?  We are interested in knowing whether 
>the document is ready to be considered for WG adoption (ie, it doesn稚
>have to be perfect at this point, but should be a good start).
>Reviews should be sent to the document authors, WG co-chairs and
>the working group secretary, and CC壇 to the MPLS WG email list. If
>necessary, comments may be sent privately to only the WG chairs.
>Are you able to review this draft by July 10, 2012. Please not that
>early reviews makes possible to enter into the next step sooner.
>as MPLS WG co-chair
>Loa Andersson                         email:
>Sr Strategy and Standards Manager  
>Ericsson Inc                          phone: +46 10 717 52 13
>                                              +46 767 72 92 13
>Mpls-review mailing list