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

[Lou Berger <[e-mail]>]

Jie,
    Please see below.

On 10/28/2014 2:31 AM, Dongjie (Jimmy) wrote:
> Hi Lou, 
>
> Thanks a lot for your review and comments, please see my replies inline: 
>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Tuesday, October 28, 2014 2:38 AM
>> To: Dongjie (Jimmy); [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-04.txt
...
>>> 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?
> You are correct, the intent is to provide a generic LI-LB mechanism, this is specified in the 2nd paragraph of the Introduction section:
>
>    " In general the LI and LB are useful Operations, Administration and
>    Maintenance (OAM) functions for technologies which use Generalized
>    Multi-Protocol Label Switching (GMPLS) as control plane, e.g.  time-
>    division multiplexing, wavelength-division multiplexing and packet
>    switching.  It is natural to use and extend the GMPLS control plane
>    protocol to provide a unified approach for LI and LB provisioning in
>    all these technologies. "
>
> And the 3rd paragraph intends to talk about the scope of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext, which is for specific MPLS-TP proactive OAM configuration and does not cover the LI&LB functions:
>
>   "[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE
>    extensions for the configuration of pro-active MPLS-TP OAM functions,
>    such as Continuity Check (CC), Connectivity Verification (CV), Delay
>    Measurement (DM) and Loss Measurement (LM).  The provisioning of on-
>    demand OAM functions such as LI and LB are not covered in that
>    document."
>
> If you think the above paragraph is a little bit confusing, we can remove it in next revision.

I've reread the section, and I think what you have is sufficient.  It
get's the points across, just had to reread it a few times...

I see that you don't list the OAM Flows Enabled (M), OAM Alarms Enabled
(O) bits defined in RFC7260.  You should include these in your next
revision.  The omission makes we want to confirm my understanding of
your intent.   As I read this document, it is your intent that: generic
lock instruct places no specific requirements on the existing flags--
OAM Flows Enabled (M), OAM Alarms Enabled (O), (protection) Lockout
(L).  You make this point implicitly by not using this flags.

Is my understanding correct?

 
>>>>>> - 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 for pointing out this. We will rephrase these sentences with appropriate 2119 language in next revision.
great - thank you.

Lou