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

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

Hi Lou, 

Thanks for your comments, please see my replies inline:

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

Thanks. We tried to make the intent clear in the introduction, I guess now you are OK with it. 

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

We forgot to list the new Flags by mistake, will add them in next revision. 

Yes we intend to make the generic LI&LB not depend on the existing flags for proactive TP OAM.

Best regards,
Jie

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