Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-07.txt

From: [email-masked]
Date: Mon, 03 Oct 2011 09:43:31 -0700

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Oct 2011 22:50:36 +0100

Hi MPLS WG,

As usual, I did my AD review of this draft when I received the publication
request. In this case, the changes I wanted to see were quite extensive and
structural. For such a short draft, if turned out to be easier to work with Sami
(as pen-holding editor) and Stewart (as one of the co-authors) to actually make
the changes rather than to try to explain what I wanted to see done.

However, I have promised to summarise the changes as effectively the output of
my review. You can find these below.

I have agreed with the MPLS Chairs that these changes are quite extensive and,
although they do not make any change of substance to the simple message that the
I-D defines, the WG should have a further last call period to make sure they are
happy with the revised text.

However, since the changes are essentially non-technical, I will also start the
IETF last call at roughly the same time so that the two run in parallel.

Thanks,
Adrian

===

AD review of draft-ietf-mpls-tp-li-lb

---

If you are updating RFC 6371, you need a normative reference. 
This will be a formal downref that needs to be called out in the shepherd
write-up and in IETF last call.

---

The Abstract is clumsy and needs to be rewritten to say what the functions are
and what the document does.
This led to the new Abstract text in the current revision.

---

Don't need a ToC in such a short document.

---

The Introduction (Section 1) contains too much detailed information. At the same
time, the descriptions of the two functions is spread out across the document. 

My proposal (as implemented) was to shorten the Introduction into much more of a
summary, and to create Sections 3 and 4 to provide the functional description of
the two functions. Material was pulled from Sections 1, 3, 4,  5, and 6 to
create the new sections 3 and 4.

---

Section 2

LSR, MPLS-OAM, and NMS are not used in the document

---

Section 3.1

Is Figure 1 necessary? If you include it, you must describe the fields.
But since it is a direct copy, you can leave it out.

We deleted it.

---

Section 3.2

You need to describe the reserved field.

---

Section 3.2 Refresh Timer

   This
   value MUST NOT be changed for the duration of that lock.

So, you need to describe what a receiver does if the value is changed.

We added text to say "MAY ignore new values"

---

Section 3.2

   MEP Source ID TLV: This is the "CC/CV MEP ID TLV" defined in [3].

A little more info?
Added text to say that this is the ID of the MEP that sent this message.

---

Section 4 didn't really add anything.
Moved the text to the new Sections 3 and 4.

---

Section 5.1

s/A MEP is locked either/A MEP is locked if either/

---

The descriptions of behavior for locking and unlocking was spread across {5.1,
5.5} and {5.2, 5.6}
This led to some cases not being covered, and a rather unfortunate
proof-by-example definition.

We merged the material to new sections describing the operational procedures.

Then we added explanations of the following questions...

What does it mean to say a MEP is "not receiving LI messages"?
How long does a MEP wait before deciding it is not receiving LI messages:
- when it has received a previous LI message
- when it has never received an LI message? 
When and how is the lock actually implemented?
What constitutes a bad LI message?
Is it wise to log every bad LI message?

---

Section 5.2

s/A MEP would unlock transport path/A MEP unlocks a transport path/

---

NOTE WELL

This is maybe a contentious change, but we could not really find any deep reason
for the text, and I was pretty sure it did not say what was meant.

Section 5.3

This appears to say that you cannot stop sending traffic on a transport path
without locking it.
i think it may have been meant to say that if you want to put the path into an
administratively locked state, you must actually lock it. 
Hopefully this is stupifyingly obvious from the document and doesn't need any
other clarification.

---

Section 5.4

The somewhat detailed example scenario described in 5.4 is barely used in 5.5.
and 5.6.
Since 5.5 and 5.6 are folded into the operational description, 5.4 is deleted.

---

Section 6

   The control plane
   protocols utilize hop-by-hop security, and assume a "chain-of-trust"
   model such that end-to-end control plane security is not used.

True but irrelevant.
Text removed.

---

Section 6

   Thus, there is no simple way of
   preventing any traffic being carried between in the G-ACh consenting
   nodes.

Between what?
Text clarified.

---

Section 7.1

s/(Section 3.1)/[This.I-D]/

---

Section 8

"D'Alessandro Alessandro Gerardo" is garbled

---

Author's Addresses

Pluralise!

---

Please separate the authors into "Editors' Addresses" for the front-
page editors, and "Contributing Authors" for everyone else.