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

["Dongjie (Jimmy)" <[e-mail]>]

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
> 
> 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.
> 

Agree with your suggestion. This could make section 2.1 much clearer.

> >> 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?

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.

> >>>> - 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.

Best regards,
Jie

> Thanks,
> Lou
> 
> ...