Subject: Re: [mpls] draft-ietf-mpls-tp-li-lb-05.txt

From: Eric Gray <[email-masked]>
Date: Fri, 16 Sep 2011 09:02:46 -0400

Sami,

	Some minor comments on the current (9/15/2011) version.

In the second para of the intro, "defines the extensions" should
be "specifies extensions"...
_________________________________________________________________

First para, page 3, a space needs to be added after "Pseudowires"
and before the open paren.  In the same para, "dedicated to the
transport path" is redundant and should be removed.
_________________________________________________________________

Next para, "tight coordination" should be "timely coordination."
_________________________________________________________________

Sixth para, page 3, this para should be broken up into multiple
paragraphs.  The following sentence should be replaced with text
similar to the suggested replacement text below, as the start of
a second paragraph:

Replace - 
"The Loopback is a function that enables a MEP to request a MEP 
 or a MIP to enter a loopback state."

With - 
"Loopback is a function that enables a receiving MEP to return 
 traffic to the sending MEP, when in the loopback state."

The sentence in the current para that starts with "Note that ..."
should probably be in a separate paragraph.
_________________________________________________________________

Next para, the sentence that starts with "It should be noted ..."
should be in a separate paragraph.  As it now stands, however,
this setence has a few issues.  I cannot parse the portion that
says "applied to data plane loopback points that can resides on
..." 

If the intent is to say that the loopback points can be part of
interfaces that are separate from applicable MEP(s) or MIP(s),
then "that can resides" should be replaced with "residing"...
_________________________________________________________________

Next para, change the paragraph to read something along the lines
of:

"For data plane loopback at an intermediate point in a transport
 path, the loopback needs to be configured to occur at either the
 ingress or egress interface.  This is done using management."

Note that loopback at both interfaces is not reasonable.
_________________________________________________________________

Next para, "insure" should be "ensure"...
_________________________________________________________________

There is an extra line-feed between the last paragraph and the
next one (starting with "The Lock function ...").
_________________________________________________________________

Next para, "tight coordination" should be "timely coordination"
(this should be done generally, as "tight" is an ambiguous term.
For instance, I find coordination difficult when I am "tight.")
_________________________________________________________________

Section 3.2, please try to keep the message format from spanning
multiple pages.
_________________________________________________________________

Section 4, second para: "sender" should be changed to "sending" 
in both instances.  While the MEP in this case is originating
test traffic, it is not exclusively a "sender."
_________________________________________________________________

Section 5.1, first para:  change to read along the lines of -

"Lock is used to request a MEP to take a transport path out of 
 service for administrative  reasons.  For example, Lock can
 be used to allow some form of maintenance to be done for a
 transport path."
_________________________________________________________________

Next para: change the first sentence to read as follows -

"When performing Lock, in response to a management request, the
 MEP MUST take the transport path out of service and MUST begin
 sending LI messages periodically to the remote MEP at the remote
 end of the transport path."
_________________________________________________________________

The next two paragraphs should be in reverse order (i.e. - talk
first about taking the transport path out of service and then
about keeping it out of service).
_________________________________________________________________

Change the next para to read:

"A MEP is locked either Lock was requested by management (and -
 as a result it is sending LI messages), or it is receiving LI
 messages from the remote MEP."

Note that "by management" is more general (and therefore more
accurate) that "by NMS" - since Lock may be requested by CLI,
or as a result of pushing a control panel button.

In general, anywhere where we currently use the term "NMS", we
should verify that the meaning is not broader than this.
_________________________________________________________________

Section 5.2, second paragraph: it is not possible to unlock a
MEP via the control plane.  If the MEP stops receiving LI, and
is itself not administratively in a Lock state, then the MEP is
required to unlock the transport path, putting it in service.

Delete "or control" from the first sentence in this paragraph.
_________________________________________________________________

Next para, "would" should be "SHALL" (i.e. - "A MEP SHALL unlock
...").
_________________________________________________________________

Next para, "NMS" should be "management" - also "no LI OAM 
messages are received" should be "no LI messages have been
received in the most recent 3.5*(Refresh Timer) seconds."
_________________________________________________________________

Section 5.3, delete "first" from the text in this section.
_________________________________________________________________

Section 5.5, change "Management system" to "management" (this is
also something to consider doing generally, for the same reason
as was described for "NMS").
_________________________________________________________________

Next para, change "event is logged. Processing ceases." to "event
is logged and processing of the LI message ceases."  This is 
necessary to ensure that 1) we use the same preconditions for
ceasing processing as we use for logging the event, and 2) so it
is unambiguous as to what it is that we are to cease processing.

The last sentence can be omitted as this is implicit in that we
have not indicated that processing should cease.
_________________________________________________________________

Section 5.6, change "Management system" to "management"...
_________________________________________________________________

Next para is not correct.  Please replace this paragraph with 
text along the lines of:

"After both MEP A and MEP D have not received an LI message in
 at least 3.5 times the refresh timer, and each MEP has not 
 received a new management request to Lock the transport path,
 both MEPs SHALL put the transport path back in service."
_________________________________________________________________

Section 6, second para - to reduce the potential for ambiguity,
replace "those two documents" with "[4] and [7]."
_________________________________________________________________

For IANA considerations, we refer to the value of the "to be
determined" (assigned by IANA) value as "0xHH"; in the IANA
Considerations section, the value is represented as "0xHHHH" 
- we should be consistent in using this representation.
_________________________________________________________________

--
Eric

---

From: Jie Dong <[email-masked]>
Date: Mon, 26 Sep 2011 05:09:51 +0000

Hi Sami, 

Here are some comments on li-lb-05. 

1. In Section 1, "The Loopback is a function that enables a MEP to request a MEP or a MIP to enter a loopback state."

This indicates loopback is a request from a MEP to a MEP/MIP, but in this document loopback is performed by management plane. Does this mean loopback may also be performed by some other ways, such as in-band OAM or control plane?

2. Section 4, "LI messages may be lost during looping or maintenance operations, thus locking both ends is required, before such operations occur."

Does "locking both ends" here mean that both ends should be locked by NMS when loopback or maintenance will be performed? If so, in which case will the LI message be used for locking one end?

Best regards,
Jie