Subject: Re: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-sd

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 3 Sep 2013 07:34:54 +0000

Eric, thanks for your comments.

At this time, I would rather not address your comments for the MPLS WG regarding the document style.
Once the appropriate style is determined by this WG, then we will update the draft accordingly.

In the meantime, I will incorporate all of your comments specific to this draft in the new version of this draft.
There is one comment I need a clarification.
You said that we need to add "updates RFC 6378 (when published)" to the header of the first page.
What do you mean by the header? Is it the title or something else? What would be the complete sentence/phrase you are suggesting?

Best regards,

Jeong-dong

________________________________
From : "Eric Gray" <[email-masked]>
Sent : 2013-08-23 22:16:44 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, Huub van Helvoort ([email-masked]) <[email-masked]>, Alessandro D Alessandro <[email-masked]>, [email-masked] <[email-masked]>
Cc : Loa Andersson <[email-masked]>, Ross Callon ([email-masked]) <[email-masked]>, George Swallow ([email-masked]) <[email-masked]>, 'Martin Vigoureux' ([email-masked]) <[email-masked]>
Subject : RE: MPLS-RT review of draft-rhd-mpls-tp-psc-sd

Hi,

I have been asked to review this draft, and to determine if it is in good enough
shape to be adopted by the MPLS working group.

Although requested to include the MPLS working group mailing list as a "Cc", I
have included it as a "To" because of the questions I think need to be resolved either
by discussion in the working group, or decision by the working group chairs.

In general, I find this draft to be well written and may be ready for adoption by the
MPLS working group. There are two general questions about what may be acceptable to
the working group that should be resolved in some way prior to adoption of this draft by
the working group. The questions are included as the first part of my comments below.

I have the following comments and/or questions:

Major Comments/Questions:
======================

General questions for the MPLS working Group
----------------------------------------------------------

First Question --
The way that this draft is written is as a "delta" to RFC 6378. I personally do not have any
problems with this, assuming that a reader can correctly (re)construct the resulting text
as applied to RFC 6378.

However, over the long term, it is significant that this "delta" will not actually be applied
to RFC 6378 and may therefore lead to ambiguity and/or confusion if other subsequent
"deltas" are produced against the same RFC in the future. When/if this happens, it is
likely that the combination of multiple "delta" RFCs will force a re-write of RFC 6378 to
remove ambiguity and/or confusion.

As an example, should a subsequent "update" to RFC 6378 suggest renumbering of the
sections affected by this document, there will likely be confusion resulting from the
order that a reader reads the set of documents, applying the changes in the order that
they read them, as opposed to the order in which they were written and intended.

Is the working group generally okay with taking this approach?

(Alternatively, this draft could be re-written as a "bis" for RFC 6378, obsoleting that RFC
as opposed to updating it, or it could be re-written as a quasi-stand-alone document -
rather than as a set of deltas to RFC 6378 - referring to RFC 6378 for protection switching
behavior not explicitly described in this document.)

Second Question --
Is it simpler to deal with this draft as a separate draft, or should it be combined with the
other related drafts that are also (at least primarily) intended to update RFC 6378?

At least with the two drafts I've been asked to review (adding signal degrade, and making
corrections to non-revertive mode), the modifications to RFC 6378 appear to be distinct,
non-overlapping, changes throughout the drafts. Where this is more difficult to be certain
of is in the changes to the state-machine tables - which are quite complex.

At various points in the process, when reviewing the draft, the best approach to verifying
that there is no overlap or inconsistency is to actually merge all of the changes and then
review the result. If this turns out to be the case for every reviewer, then there is no
benefit to having these as separate drafts.

Should all of these related drafts be merged?

Minor Comments and NITs:
====================

You need to add "updates RFC 6378 (when published)" to the header of the first page.

The title could be shortened by removing both instances of "the" (neither article is helpful).

In the published form, the Abstract MUST NOT say "contains the updates to [RFC6378]" as
other documents will "contain updates" to RFC 6378 at some point in the future as well.

I note that this is already the case, with other drafts in progress.

I suggest omitting "contains the updates to" from the abstract, replacing it with "updates"
and adding a second comma after "Linear Protection" (the text "MPLS Transport Profile ...
Linear Protection" is a parenthetical description of RFC 6378). The same comment applies
to the Introduction section as well.

In the first paragraph of the Introduction, "a fault condition includes" is grammatically
incorrect. I suggest "fault conditions include" instead.

Prior to the second paragraph of the Introduction, you have not yet used/explained that
"MPLS Transport Profile (MPLS-TP) Linear Protection" and "PSC" are equivalent. I suggest
either adding a short paragraph before this paragraph that explains this, or not using the
Acronym "PSC" until after section 3.

Also I am uncertain that it is precisely correct to refer to RFC 6378 as "the PSC document."

I suggest inserting a new paragraph along the lines of:

"The PSC protocol is defined in RFC 6378."

And then replace delete "The PSC document" at the start of the next paragraph.

In the current second paragraph of the Introduction, I suggest replacing "but" with "and"
(I believe your point is that these are both inadequacies of RFC 6378 - the fact that it does
not specify how declaration is done for either fault _and_ that it only describes protection
switching for the SF case).

"PSC" needs to be added to section 3 ("Acronyms").

The "lingua Franca" for IETF drafts and RFCs is _American_ English, so "behavior" not
"behaviour" (e.g. - section 4, first and fifth lines of the first paragraph).

As a question, should we be trying to be consistent in the use of capitalization with the
phrase "Signal Degrade" (you have it in lower case at several points in the draft)?

In section 5.2, I have a slight problem with the wording relating to configuration of the
protection domain for revertive behavior. However, the issue existed in the original
text in RFC 6378, hence I consider this a minor issue at this point. The issue I have is
that there are two conditions that are applicable to the behavior:

1) when recovering from ... condition on the working path
and
2) when the protection domain has been configured for revertive behavior.

It is not clear (probably because of the ordering) that configuring the protection domain
for revertive behavior is something that would have been done prior to recovery from a
failure or degradation condition.

It is very likely that simply re-ordering the text will clear this up.

--
Eric Gray