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

From: [email-masked]
Date: Mon, 20 Oct 2014 00:43:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

        Title           : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
        Authors         : Jie Dong
                          Mach(Guoyi) Chen
                          Zhenqiang Li
                          Daniele Ceccarelli
	Filename        : draft-ietf-ccamp-rsvp-te-li-lb-04.txt
	Pages           : 8
	Date            : 2014-10-20

Abstract:
   This document specifies extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
   Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These
   mechanisms are applicable to technologies which use Generalized
   Multi-Protocol Label Switching (GMPLS) as control plane.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-li-lb/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-li-lb-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-li-lb-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 20 Oct 2014 07:58:27 +0000

Dear all, 

The only change in this new version is: 

- Update the references (one has become RFC)

Your review and comments are highly appreciated.

Many thanks,
Jie

> -----Original Message-----
> From: CCAMP [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, October 20, 2014 3:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-04.txt
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2014 15:30:08 -0400

Jie, Authors,
    I have a few comments:

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

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

Where is the Loopback (B) bit / Attribute Flag defined? This document,
right? Then the document, needs to state so in this section and in the
IANA section.

Section 4, needs to be updated to follow RFC2360, See
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-10
for a recent example.

- Also please cleanup your id-nits, see
http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-ccamp-rsvp-te-li-lb-04.txt

Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 23 Oct 2014 03:43:30 +0000

Hi Lou, 

Thanks a lot for your review and comments, please see my replies inline:

> Jie, Authors,
>     I have a few comments:
> 
> - 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.

> Where is the Loopback (B) bit / Attribute Flag defined? This document, right?
> Then the document, needs to state so in this section and in the IANA section.

The Loopback bit was defined in the end of section 2 "Extensions to RSVP-TE". To make it clearer, will use subsections for each extension in the new revision.

> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-1

Thanks for pointing to this example. Will update the IANA section accordingly.

> http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-ccamp-rsvp-t

Will clean this in the new revision.

Best regards,
Jie

> >>         Title           : GMPLS RSVP-TE Extensions for Lock Instruct
> and
> >> Loopback
> >>         Authors         : Jie Dong
> >>                           Mach(Guoyi) Chen
> >>                           Zhenqiang Li
> >>                           Daniele Ceccarelli
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Oct 2014 08:51:51 -0400

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

> We will rephrase the sentence to make it clearer.
Great.  Please include appropriate conformance language.

> The Loopback bit was defined in the end of section 2 "Extensions to RSVP-TE". To make it clearer, will use subsections for each extension in the new revision.

This is a good change to section 2. You might want to rename that
section encodings or formats as the whole document is about rsvp-te
extensions. You can take a look at section 4 of
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp as a recent example. 

This said, you still need to mention where it is defined (e.g., in
section 3.1, add "defined above" the first time you mention the bit) and
add it to the IANA section.

> Will clean this in the new revision.

Thanks,
Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 25 Oct 2014 06:11:43 +0000

Hi Lou, 

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

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

Will fix this in the new revision.

> > The Loopback bit was defined in the end of section 2 "Extensions to RSVP-TE".
> To make it clearer, will use subsections for each extension in the new revision.
> 
> This is a good change to section 2. You might want to rename that section
> encodings or formats as the whole document is about rsvp-te extensions. You
> can take a look at section 4 of
> This said, you still need to mention where it is defined (e.g., in section 3.1, add
> "defined above" the first time you mention the bit) and add it to the IANA
> section.
>

Will fix this in the new revision.

Many thanks, 
Jie

> >> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ
> >> ated-lsp-1
> >> 0
> >> for a recent example.
> >> http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf
> >> -ccamp-rsvp-t
> >> e-li-lb-04.txt

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Oct 2014 14:38:04 -0400

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. 

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

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?

> 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

...

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Oct 2014 06:31:02 +0000

Hi Lou, 

Thanks a lot for your review and comments, please see my replies inline: 

> From: Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, October 28, 2014 2:38 AM
> To: Dongjie (Jimmy); [email-masked]
> Cc: [email-masked]
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-li-lb-04.txt
> 
> Jie/Authors,
> 

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

> > 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 ..."
> >> 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.
>     The loopback request is acceptable only when the LSP is already in lock
> mode.
> 

Thanks for pointing out this. We will rephrase these sentences with appropriate 2119 language in next revision.

Best regards,
Jie

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Oct 2014 15:18:01 -0400

Jie,
    Please see below.

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

> Thanks for pointing out this. We will rephrase these sentences with appropriate 2119 language in next revision.
great - thank you.

Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 30 Oct 2014 02:41:25 +0000

Hi Lou, 

Thanks for your comments, please see my replies inline:

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

> (O) bits defined in RFC7260.  You should include these in your next revision.
> The omission makes we want to confirm my understanding of
> 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.
> 

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

> >>>>>> is unchanged by this document so think you should drop the 3
> >>>>>> lines that contain
> >>>> the phrase "...
> >>>>>> intermediate nodes ..."
> >>>>>> 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.
> >>>> 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.
> >>     The loopback request is acceptable only when the LSP is already
> >> in lock mode.
> >>
> >> 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
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 30 Oct 2014 06:28:02 +0000

Hi Lou, 

> Yes we intend to make the generic LI&LB not depend on the existing flags for

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Oct 2014 08:55:21 -0400

Jie,
    See below.

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

It sounds like the next version will resolve the (minor) open issues.
Correct? 

Thanks,
Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 31 Oct 2014 06:04:50 +0000

Hi Lou, 

> It sounds like the next version will resolve the (minor) open issues.

Yes, we will submit the new revision once the submission system opens again.

Best regards,
Jie