Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-04.txt

Lou Berger <> Mon, 27 October 2014 18:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 801B71ACCFD for <>; Mon, 27 Oct 2014 11:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QIyNb2Mmin3D for <>; Mon, 27 Oct 2014 11:41:16 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 277771ACE76 for <>; Mon, 27 Oct 2014 11:38:00 -0700 (PDT)
Received: (qmail 10451 invoked by uid 0); 27 Oct 2014 18:37:59 -0000
Received: from unknown (HELO cmgw4) ( by with SMTP; 27 Oct 2014 18:37:59 -0000
Received: from ([]) by cmgw4 with id 8Qdv1p00M2SSUrH01QdyXX; Mon, 27 Oct 2014 18:37:58 -0600
X-Authority-Analysis: v=2.1 cv=fdw+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=R93LHVwsjZ-F47kZ7GcA:9 a=wPNLvfGTeEIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=P/gwAlVvU2z3mJOa6X86dGwCdymyKRznaNUWr9nD/kA=; b=BlBLZl3c/kK2KRyylulf3229oGurfCQ/D8g6ova8CB7yKSN31ONmgZXp+lgo7SHS+QyUpiKWkhKI/BIcUfFSzwy5N/aY7zBxHb0IwqSDCnqfU9uRPc0ezlTotIFVajFN;
Received: from ([]:34210 helo=[]) by with esmtpa (Exim 4.82) (envelope-from <>) id 1XipAx-0000Gk-NP; Mon, 27 Oct 2014 12:37:55 -0600
Message-ID: <>
Date: Mon, 27 Oct 2014 14:38:04 -0400
From: Lou Berger <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Dongjie (Jimmy)" <>, "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {} {sentby:smtp auth authed with}
Cc: "" <>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Oct 2014 18:41:19 -0000


    Thank you for the update, please see below for additional responses.

WRT section 2.1.  Extensions for Lock Instruct:
- What extension is defined in this subsection.  What do you think about
replacing section 2.1 with something along the lines of?

  2.1. Lock Instruct Indication

   In order to indicate the lock/unlock of the LSP, the A
   (Administratively down) bit in ADMIN_STATUS object [RFC3471]
   [RFC3473] is used. 

On 10/25/2014 2:11 AM, Dongjie (Jimmy) wrote:
> Hi Lou, 
> Thank you for your comments and suggestions. We will submit a new revision to reflect them. Please see my replies inline:
>> Jie,
>>     Thank you for the quick response.  See below for responses.
>> It probably would also be worthwhile to add some words on when this
>> extension should be used versus draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext
>> <>.
> In some earlier version there used to be some words talking about draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and this draft, we will add some words back in the new revision. 
> Basically draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext defines extensions for configuring pro-active MPLS-TP OAMs, while draft-ietf-ccamp-rsvp-te-li-lb is about LI & LB provisioning, which belong to on-demand OAM functions.

Hum, I'm not sure I would have gone this way.  My recollection was that
the intent of this document was to provide a generic (non-TP, specific)
mechanisms for LI-LB.  Do I have it wrong?

>>>> - Section 3.1,
>>>> I think intermediate node behavior related to processing of the A is
>>>> unchanged by this document so think you should drop the 3 lines that contain
>> the phrase "...
>>>> intermediate nodes ..."
>>> Agree the behavior of intermediate node is unchanged, will remove the
>> descriptions about intermediate node behavior in a new revision.
>>>> - Section 3.2
>>>> The section is not clear if the A bit processing occurs / completes
>>>> before Loopback related processing begins or occurs coincidentally.
>>>> (I read the last sentence of the first paragraph saying the former
>>>> and the last sentence of the 2nd paragraph saying the latter.)  Either way it
>> should be clarified.
>>> The A bit (lock) processing needs to be completed before initiating loopback
>> request. The last sentence of the 2nd paragraph was to emphasize that when
>> signaling loopback, the A bit should be kept set to indicate the LSP is still in lock
>> mode.
>>> We will rephrase the sentence to make it clearer.
>> Great.  Please include appropriate conformance language.
> Will fix this in the new revision.

I think the following should be rephrased to include 2119 language:
    The loopback request is acceptable only when the LSP is already in
lock mode.

If this statement is true, shouldn't the following SHOULDs  be MUSTs?
   The Administratively down (A) bit in
   ADMIN_STATUS object SHOULD be kept set to indicate that the LSP is
   still in lock mode.
   Administratively down (A) bit in ADMIN_STATUS object SHOULD be  kept
   set to indicate the LSP is still in lock mode.
   The Administratively down
   (A) Bit in ADMIN_STATUS Object SHOULD be  kept set in the Resv

It probably would be worthwhile to state that the Lock Instruct MAY be
removed once the Loopback is cleared.