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

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

Hi Lou, 

Some updates on my replies: 

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

Sorry in previous mail I mixed up draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext with RFC7260. While still our intent is that generic LI&LB has no specific requirement on those existing flags. 

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