Subject: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Oct 2011 18:34:33 -0700

Dear Authors, Editors, et al.
Below are my notes and comments to the latest version of LI/LB document:

   - I couldn't find Table of Contents in this version.
   - Introduction, third para. Applicability of the Loopback is limited,
   comparing to previous versions, to bi-directional co-routed LSP, PW and MPLS
   Section. I agree that statement of applicability in previous versions was
   bit too cumbersome but this one excludes bi-directional associated LSP at
   all. I think that Loopback can be used on this construct at MIP that are on
   forward and reverse direction of given bi-directional associated MPLS-TP
   LSP. And I think that MPLS Section is not necessarily a bi-directional
   co-routed object.
   - p.3, third para though "despatch - a less common spelling of dispatch"
   might consider 's/despatch/dispatch/'
   - Section 3, last para on p.3, s/PW/PWs/
   - Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point) or
   consider s/receiving MEP/MP/ since text in the sentence refers to it being
   in the loopback state.
   - Section 4, p.4, second to last para. I think that management plane sets
   in or requests Loopback on specific MP but not performs it.
   - Section 4.1, first bullet s/e/be/
   - Definition given in Section 4.1 is broader than one in the
   Introduction. Personally I like the latter better though I think that it can
   be expanded to include MIPs on bi-directional associated LSP that are on
   forward and reverse direction of it.
   - Section 4.1, s/LSPs, PW,/LSPs, PWs,/
   - Section 6.2 I think that UnLocking implies that a management process
   must send Unlocked command on both MEPs. In previous version absence of LI
   OAM for 3.5 times of Refresh Timer would have unlocked the transport path.
   The old definition of UnLock procedure was missing the fact that LI messages
   would not be delivered past LB but the new one makes it exclusive function
   of NMS or management plane. Is that desired?
   - Section 6.2 have changed how Refresh Timer used. Previous versions
   based UnLocking on Refresh Timer while now it is used to schedule turning a
   transport path back to service after it was explicitly UnLocked. I'll note
   that service could not be restored faster than in 3.5 seconds according to
   described procedure. Is that desired behavior?

Regards,
Greg

On Mon, Oct 3, 2011 at 9:43 AM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multiprotocol Label Switching
> Working Group of the IETF.
>
>        Title           : MPLS Transport Profile lock Instruct and Loopback
> Functions
>        Author(s)       : Sami Boutros
>                          Siva Sivabalan
>                          Rahul Aggarwal
>                          Martin Vigoureux
>                          Xuehui Dai
>        Filename        : draft-ietf-mpls-tp-li-lb-07.txt
>        Pages           : 11
>        Date            : 2011-10-03
>
>   Two useful Operations, Administration, and Maintenance (OAM)
>   functions in a transport network are &quot;lock&quot; and
> &quot;loopback&quot;. The lock
>   function enables an operator to lock a transport path such that it
>   does not carry client traffic, but can continue to carry OAM messages
>   and may carry test traffic. The loopback function allows an operator
>   to set a specific node on the transport path into loopback mode such
>   that it returns all received data.
>
>   This document specifies the lock function for MPLS networks and
>   describes how the loopback function operates in MPLS networks.
>
>   This document updates RFC 6371 section 7.1.1.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 04 Oct 2011 08:48:49 +0100

On 04/10/2011 02:34, Greg Mirsky wrote:
>   * I couldn't find Table of Contents in this version.
>
Hi Greg

A table of contents is optional in a document less that 15 pages long.
(http://www.ietf.org/id-info/guidelines.html)

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Oct 2011 09:57:15 +0200

Stewart,

that is correct - it is an option not to have the a table of content.

However it is also an option to have it, the fact that people asks for
the toc has earlier lead to a recommendation from wg chairs to include
a toc if the the authors think it is beneficial; i.e. not read the
recommendation as "you can't use a toc if the ID is shorter than 15
pages".

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Oct 2011 22:24:51 +0100

Hi Greg,

Thanks for reading. Let me answer since a lot of the text was mine.

> I couldn't find Table of Contents in this version. 

I guess Loa and I can disagree :-) 
There are about 8 pages of real text in the document, not enough for a ToC IMHO

> Introduction, third para.
> Applicability of the Loopback is limited, comparing to previous versions,
> to bi-directional co-routed LSP, PW and MPLS Section. I agree that 
> statement of applicability in previous versions was bit too cumbersome 
> but this one excludes bi-directional associated LSP at all. I think that
Loopback
>  can be used on this construct at MIP that are on forward and reverse
direction
> of given bi-directional associated MPLS-TP LSP. And I think that MPLS Section 
> is not necessarily a bi-directional co-routed object.

Reading too fast?

The bullet says...

   - The loopback function allows an operator to set a specific node on
     a transport path into loopback mode such that it returns all
     received data. Loopback can be applied at a Maintenance Entity
     Group End Point (MEP) or a Maintenance Entity Group Intermediate
     Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
     Section. It can also be applied at a MEP on an associated
     bidirectional LSP, PW or MPLS Section.

That seems to cover exactly the same cases (including associated bidir) as in
the previous version.

> p.3, third para though "despatch - a less common spelling of dispatch"

Shall we let the RFC Editor worry about differences between UK and US English?
"despatch. Same as dispatch" - Chambers 20th Century Dictionary

> Section 3, last para on p.3, s/PW/PWs/

yes

> Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point)
> or consider s/receiving MEP/MP/ since text in the sentence refers to it
> being in the loopback state.

Good catch.
Not sure if "MP" is known term.
Can we say "receiving MEP or MIP" ?

> Section 4, p.4, second to last para. I think that management plane
> sets in or requests Loopback on specific MP but not performs it.

The two sentences in this paragraph are directly copied from the precious
revision with the only change to drop "MUST" to lower case.

Not sure what to say here since the WG clearly agreed to this text before.
I think the intention was to say that a control plane is not required in order
to achieve loopback.

> Section 4.1, first bullet s/e/be/

Yes

> Definition given in Section 4.1 is broader than one in the Introduction. 
> Personally I like the latter better though I think that it can be expanded
> to include MIPs on bi-directional associated LSP that are on forward and
> reverse direction of it.

I think it is the same definition.
See the paragraph quoted above and compare with:
   - The node in loopback mode must be on both the forward and return
     paths. This possible for all MEPs and MIPs on a co-routed
     bidirectional LSP, PW, or MPLS Section, but is only
     possible on for MEPs on associated bidirectional LSPs, PW,
     or MPLS Sections.
...which seems to exclude the MIPs on assoc bidir as you say.

> Section 4.1, s/LSPs, PW,/LSPs, PWs,/

Yes

> Section 6.2 I think that UnLocking implies that a management process
> must send Unlocked command on both MEPs. In previous version
> absence of LI OAM for 3.5 times of Refresh Timer would have unlocked
> the transport path. The old definition of UnLock procedure was missing
> the fact that LI messages would not be delivered past LB but the new
> one makes it exclusive function of NMS or management plane. Is that
> desired?

I think that you have highlighted one of the problems with the previous version.
It was confusing!

However, absence of LI would NOT have unlocked a MEP when a lock command had
previously been issued to that MEP.

>From the old section 5.2
   A MEP would unlock transport path and put it back to service if and
   only if there is no management request to lock the path and it is not
   receiving in-band LI messages.

   A MEP is unlocked when there is no management request to Lock and no
   LI OAM messages are received.

The old document did also mention that LI might go AWOL and said in Section 4:
   LI
   messages may be lost during looping or maintenance operations, thus
   locking both ends is required, before such operations occur.

I don't believe the new version has made any functional change.

> Section 6.2 have changed how Refresh Timer used. Previous versions
> based UnLocking on Refresh Timer while now it is used to schedule
> turning a transport path back to service after it was explicitly UnLocked.

As above, I don't believe the new version has changed what was described,
however...

> I'll note that service could not be restored faster than in 3.5 seconds
according
> to described procedure. Is that desired behavior?

That is a good question for the WG. It was my assumption (from the previous
revision) that rapid unlocking and turn-up was not a requirement or it would
have been included.

If the WG now wants to include it, it will need to examine the use of an unlock
OAM message. This could be done using a new message or a flag on the existing
lock message. It could be achieved by tweaking this document or introducing a
new document.

Cheers,
Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Oct 2011 14:59:11 -0700

Hi Adrian,
greatly appreciate your kind consideration of my notes. I've in-lined mine
and tagged with GIM>>

Regards,
Greg

> There are about 8 pages of real text in the document, not enough for a ToC
GIM>> I'm OK either way

> > is not necessarily a bi-directional co-routed object.
GIM>> Yep, sorry, cognitive filter ;)
GIM>> But then PW and MPLS Section have been referred twice - after
co-routed LSP, then after associated LSP. Or intention was to apply
co-routed and associated to PW and MPLS Section? Would making the last
sentence to "It can also be applied at a MEP on an associated bidirectional
LSP" be sufficient? But still, MIPs that are on forward and reverse
direction of an associated bi-directional LSP are excluded. I believe that
previous versions tried to include such MIPs since these are required to be
aware of directions and their correlation. Is this change intentional?

> Can we say "receiving MEP or MIP" ?
GIM>> Works for me

> I think the intention was to say that a control plane is not required in
GIM>> What if the first sentence says:
A management plane can be too used to set a MEP or MIP along a transport
path in Loopback.

> lock message. It could be achieved by tweaking this document or introducing
GIM>> I'd support explicit UnLock OAM message. I think that it is required
if LI/LB expected to work in heterogeneous network (without defined UnLock
message or flag request to UnLock is proprietary, in my view).

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Oct 2011 11:43:19 +0100

Hi again Greg,

We are converging.

I've cut out the bits where we have reached conclusions.

>>> Loopback can be used on this construct at MIP that are on forward 
>>> and reverse direction of given bi-directional associated MPLS-TP LSP. 
>>> And I think that MPLS Section is not necessarily a bi-directional co-
>>> routed object.
>
> GIM>> But then PW and MPLS Section have been referred twice - 
> after co-routed LSP, then after associated LSP. Or intention was to apply
> co-routed and associated to PW and MPLS Section? Would making the 
> last sentence to "It can also be applied at a MEP on an associated
> bidirectional LSP" be sufficient? But still, MIPs that are on forward
> and reverse direction of an associated bi-directional LSP are excluded. 
> I believe that previous versions tried to include such MIPs since these
> are required to be aware of directions and their correlation. Is this
> change intentional?

You're right. I mangled the original  text in my enthusiasm to have something I
could parse :-)
I think there are two issues:

1. extraneous mention of PW and Section in the last sentence

OLD (v7)
   - The loopback function allows an operator to set a specific node on
     a transport path into loopback mode such that it returns all
     received data. Loopback can be applied at a Maintenance Entity
     Group End Point (MEP) or a Maintenance Entity Group Intermediate
     Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
     Section. It can also be applied at a MEP on an associated
     bidirectional LSP, PW or MPLS Section.
NEW
   - The loopback function allows an operator to set a specific node on
     a transport path into loopback mode such that it returns all
     received data. Loopback can be applied at a Maintenance Entity
     Group End Point (MEP) or a Maintenance Entity Group Intermediate
     Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an
     MPLS Section. It can also be applied at a MEP on an associated
     bidirectional LSP.
END

2. Discussion of loopback at "coincident" MIPs on associated bidirectional LSPs.
This is a question for the WG not for me (I am only trying to provide an
editorial service!).
Would you mind raising this as a separate thread so that the WG spot and debate
the issue?

>> The two sentences in this paragraph are directly copied from the
>> previous revision with the only change to drop "MUST" to lower case.
>>
>> Not sure what to say here since the WG clearly agreed to this text
>> before. I think the intention was to say that a control plane is not
>> required in order to achieve loopback.
>
> A management plane can be too used to set a MEP or MIP along a
> transport path in Loopback. 

Well, I don't like "too" because this document doesn't actually mention any way
to set loopback using the control plane.

So what about:

OLD (v7)
   The Loopback can be performed using a management plane. Management
   plane must ensure that the two MEPs are locked before performing the
   loopback function.
NEW
   The management plane can be used to configure the Loopback function.
   The management plane must ensure that the two MEPs are locked before
   performing the loopback function.
END

>> ...which seems to exclude the MIPs on assoc bidir as you say.

Same two issues:

1.
OLD (v7)
   - The node in loopback mode must be on both the forward and return
     paths. This possible for all MEPs and MIPs on a co-routed
     bidirectional LSP, PW, or MPLS Section, but is only
     possible on for MEPs on associated bidirectional LSPs, PW,
     or MPLS Sections.
NEW
   - The node in loopback mode must be on both the forward and return
     paths. This possible for all MEPs and MIPs on a co-routed
     bidirectional LSP, on a PW, or on an MPLS Section, but is only
     possible on for MEPs on associated bidirectional LSPs.
END

2. You will raise associated bidir MIPs on the mailing list

>>> according to described procedure. Is that desired behavior?
>>
>> That is a good question for the WG. It was my assumption (from the
>> previous revision) that rapid unlocking and turn-up was not a 
>> requirement or it would have been included.
>>
>> If the WG now wants to include it, it will need to examine the use of an
>> unlock OAM message. This could be done using a new message or a flag
>> on the existing lock message. It could be achieved by tweaking this
>> document or introducing a new document.
>
> if LI/LB expected to work in heterogeneous network (without defined
> UnLock message or flag request to UnLock is proprietary, in my view).

OK. Well, this is another technical, not editorial, change.
So I am not really in a position to discuss it.
Would you mind creating a separate thread for this one as well?
That way the WG can decide what it wants to do.

Many thanks for the thorough and thoughtful review.

Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Oct 2011 10:13:05 -0700

Hi Adrian,
yes we're! And I'll try to summarize it below instead of in-lining:

   - query the WG on applicability of the LB on "coincidental" bidirectional
   MIP on associated bi-directional LSP;
   - query the WG on introducing explicit UnLock operation to MPLS-TP OAM
   set
   - I accept proposed updates to LB applicability statement
   - In regard to our discussion of management plane role in setting MEP or
   MIP into a loopback state (Section 4, p.4, second to last para). I agree
   with the proposed version for the first sentence but will re-word the
   second:

NEW
  The management plane must ensure that the two MEPs are locked before
  performing the loopback function.
NEWER
  The management plane must ensure that the two MEPs are locked before it
requests
  setting MEP or MIP in the loopback state.
END

   - I feel that we're implicitly view and refer to an MPLS Section as
   bidirectional construct even though it is not. In case of this document I'd
   propose to explicitly refer to bidirectional MPLS Section where necessary.

Regards,
Greg

---

From: Sami Boutros <[email-masked]>
Date: Mon, 10 Oct 2011 16:28:42 -0700

Hi Greg/Adrian,

Few comments inline..
At 10:13 AM 10/5/2011, Greg Mirsky wrote:
>    * query the WG on applicability of the LB on "coincidental" 
> bidirectional MIP on associated bi-directional LSP;
Sami: we can extend the applicability to this if the WG is ok with 
that, given that the MIP will be bidirectional.

>    * query the WG on introducing explicit UnLock operation to MPLS-TP OAM set
Sami: I don't think that adding an explicit UnLock is justifiable, 
given that (1) the UnLock message itself may not get through if the 
LSP is out of service.(2) The need of the lock message is for getting 
an LSP out of service in a coordinated way within a tight window, 
however an LSP coming out of service will not be fully operational 
except after other OAM functions like cc-cv will declare the LSP UP.

>    * I accept proposed updates to LB applicability statement

Sami: I accepted all the editorial texts below and will be making the 
changes as soon as the WG last call ends in the newer version 08.

Thanks,

Sami

>    * In regard to our discussion of management plane role in 
> setting MEP or MIP into a loopback state (Section 4, p.4, second to 
> last para). I agree with the proposed version for the first 
> sentence but will re-word the second:
>NEW
>   The management plane must ensure that the two MEPs are locked 
> before it requests
>    * I feel that we're implicitly view and refer to an MPLS Section 
> as bidirectional construct even though it is not. In case of this 
> document I'd propose to explicitly refer to bidirectional MPLS 
> Section where necessary.
>
>Regards,
>Greg
>
>
>On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel 
><<mailto:[email-masked]>[email-masked]> wrote:
>Hi again Greg,
>
>We are converging.
>