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

[Lou Berger <[e-mail]>]

Jie/Authors,

    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
>> <http://tools.ietf.org/wg/ccamp/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.
and
   The
   Administratively down (A) bit in ADMIN_STATUS object SHOULD be  kept
   set to indicate the LSP is still in lock mode.
and
   The Administratively down
   (A) Bit in ADMIN_STATUS Object SHOULD be  kept set in the Resv
   message.

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

Thanks,
Lou

...