Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

[정태식 <[e-mail]>]

Hi Yaacov,

Thank you for reviewing draft-cdh-mpls-tp-psc-non-revertive-00.

I discussed your comments with the other co-authors of this draft.
Some of your comments are not only related to this draft but also related to all other psc drafts.
So, I will answer only to the comments specific to this draft. Please see [Taesik] inline.

Best regards,
Taesik

From: [e-mail] [mailto:[e-mail]] On Behalf Of Yaacov Weingarten
Sent: Friday, August 23, 2013 3:56 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Hi,

I have conducted a review of draft-cdh-mpls-tp-psc-non-revertive as requested by the WG Chairs and have the following notes:

This draft purports to "update" RFC6378 to change non-revertive behavior of the Linear Protection protocol. The method of updating the protocol is through the addition of a Manual Switch to Working operator command to affect the reversion of traffic to the working path. Along the way the authors propose to change the name of the Manual Switch operator command already defined in RFC6378 and also change the name of the Protecting Administrative State to Switching Administrative State.

The format of the draft is in the form of an errata correction document, indicating which paragraphs in the RFC should be replaced and what new text should be substituted in its place.

This draft is part of a set of drafts that was discussed at the IETF87 meeting that will include an "overview" document that describes how to incorporate the new functionality described in those drafts.

With this introduction I would like to make the following observations:
1. There are accepted methods used in the IETF to update a RFC by adding new functionality to a protocol. Usually, this is done by writing a draft that describes the new functionality on top of the existing functionality rather than the method used here. This is especially strange considering that they are not changing the behavior of the existing functionality but just adding an additional command and describing its behavior.

2. Based on this observation and the fact that all of the suggested "corrections" to the text involving "Manual Switch" are to change the name but not the functionality, I do not see the justification in changing the name of the existing Manual Switch command since its functionality is essentially remaining as defined and there is no cause for confusion with the new "Manual Switch to Working" command.
[Taesik] For the sake of clarity I believe it is better to rename MS to MS-P to clearly distinguish it from MS-W and for having “symmetric names”. But I can live with current name.

3. I see problems with the suggestion to change the "Protecting Administrative State" to "Switching Administrative State" since this requires the confusing statement (in Section 4.9) "the user traffic SHALL be transported on either the protection path or the working path" which is certainly always true for traffic that is being transported. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just use Normal state?
[Taesik] Yes, traffic always flow on either the working or protection path. But, it should be noted that it is “administratively” controlled. In that sense, we cannot say that a node is in “Normal state” when MS-W command is issued. By replacing “Protecting administrative state” by “Switching administrative state”, it can cover both cases: administratively switched to working path (by MS-W) and administratively switched to protection path (by MS-P).

4.An observation that I made to the psc-priority draft is applicable to this draft as well - I do not understand the referencing of an LS from ITU - this is not a standards document, just a contribution for discussion and should not be referenced.
[Taesik] It can be reflected in the next revision of the draft.

5.Section 4.8 of this document highlights a problem that is raised by this set of drafts and their method of presentation. In this section, a "correction" is proposed for text that appears in RFC6378 section 4.3.3.2. This "corrects" the original text with new text. However, this text is also "corrected" in the psc-priority draft! Now the question that needs to be asked is which correction is the definitive correction - the one in this draft or the one in the other draft? Is this dependent upon the order in which the drafts will be published?

6. Section 4.6 of the draft presents a very lengthy description of an "algorithm" for resolving the priority of inputs "having equal priority". The case of inputs having the same priority are those in which the MS and MS-W inputs are received. I believe that this set of rules are rather confusing and the upshot of the explanation seems to be that either you use the rule of "first-come first-served" or that MS-W has higher priority, except in some very specific conditions. I am certain that this could be more clearly stated or explained.
[Taesik] It can be revised in the next version of the draft. I will appreciate if you can propose any text changes for this section.

Bottom line, I do not think that this draft is ready for WG acceptance. I would suggest that it be rewritten to update the new functionality that is being proposed while leaving the existing non-changed functionality as is. I also suggest that the format not be based on "corrections" to the existing draft - this is not a contribution to a "living" document, but rather a new document that updates the previous document.

Hope this helps,
yaacov weingarten

On Thu, Aug 22, 2013 at 12:05 PM, Mach Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I have done my MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00, here are my comments:

I think that modification to Non-revertive mode, adding MS-W and renaming MS to MS-F are valid points. But I not sure whether there is a need to replace " Protecting administrative state" to "Switching administrative state".

Read through the draft, it gives me the feeling that the draft just lists a set of erratas, I am not sure that this is the right way to progress the draft as it be. If the WG have the consensus on the content of the draft, IMHO, it's better to do a bis to RFC6378.

Minor comment:
It's better to expand the acronym when first use, for example the MS-F and MS-W, I have to guess the meaning of until I see the Acronyms section.

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Friday, August 09, 2013 8:01 PM
> To: Eric Osborne (eosborne); Eric Gray; [e-mail]<mailto:[e-mail]>; Yaacov
> Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, Wim
> (Wim); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> VIGOUREUX, MARTIN (MARTIN)
> Subject: MPLS-RT review of mpls psc documents
>
> Eric, Eric, Kenji, Yacoov, Sam, Mach, Kamran, Wim, Thomas and Markus,
>
> You been selected as MPLS-RT reviewers for a set of psc document that we
> will start progress through the mpls working group.
>
> The normal rules and question for an MPLS-RT apply:
>
> ---------- quote from a standard mail initiating MPLS-RT review -------
>
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
>
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  We are interested
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but should be
> a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
> may be sent privately to only the WG chairs.
>
> ---------------------- end quote -------------------------
>
> The only difference is that we take on more than one document and that
> there are such inter-dependencies that we want to coordinate how they
> are progressed through IETF.
>
> Please respond (at least) to the wg chairs and Martin that you are
> willing/un-willing to undertake the reviews.
>
> Since we are starting MPLS-RT reviews of 5 documents, with 4 reviewers
> for each document and each reviewer have two documents, you'll need
> to send the review with the draft name in the subject line, i.e. do
> not respond to this mail with your review comments.
>
> There is also a "PSC modes" document in the pipe, currently it is our
> opinion that this document is necessary when we will start the wglc's
> but is not necessary to make the other drafts wg documents.
>
> Can you please finish your reviews eob August 23, 2013.
>
> Here is the list of reviewers per document:
>
> draft-rhd-mpls-tp-psc-priority
> ------------------------------
> mach chen
> thomas morin
> yacoov weingarten
> Wim Henderickx
>
> draft-cdh-mpls-tp-psc-non-revertive
> -----------------------------------
> mach chen
> eric osborne
> eric gray
> yacoov weingarten
>
> draft-rhd-mpls-tp-psc-sd
> ------------------------
> eric osborne
> sam aldrin
> eric gray
> kamran raza
>
> draft-dj-mpls-tp-exer-psc
> -------------------------
> sam aldrin
> markus jork
> kamran raza
> kenji fuhira
>
> draft-osborne-mpls-psc-updates
> ------------------------------
> markus jork
> thomas morin
> kenji fuhira
> Wim Henderickx
>
>
> Authors,
>
> Please do not update the documents during the review period, we will
> tell you when the review period has ended.
>
> When we close the review period you'll need to address the comments
> from the reviewers and communicate with them (preferably on the mpls
> wg mailing list) to make sure that they are comfortable with how the
> comments has been addressed.
>
>
> /Loa
> for the mpls wg chairs
>
> --
>
>
> Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
> Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Still looking for new opportunity