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

From: Mach Chen <[email-masked]>
Date: Thu, 22 Aug 2013 09:05:58 +0000

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:[email-masked]]
> Sent: Friday, August 09, 2013 8:01 PM
> To: Eric Osborne (eosborne); Eric Gray; [email-masked]; Yaacov
> Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, Wim
> (Wim); [email-masked]; [email-masked]
> Cc: [email-masked];
> [email-masked];
> [email-masked];
> [email-masked];
> [email-masked]; [email-masked];
> 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: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 22 Aug 2013 21:56:10 +0300

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.

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?

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.

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.

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 <[email-masked]> wrote:

> 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
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: 정태식 <[email-masked]>
Date: Mon, 26 Aug 2013 02:46:49 +0000

Hi Mach,

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

As one of authors of the draft, I answered your comments.
Please see inline.

Best regards,
Taesik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, August 22, 2013 6:06 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Hi,

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".
[Taesik] I guess "MS-W" as "MS-P" because the draft does not use the term "MS-F". 
[Taesik] According to Sec 3.6 of RFC6378, “Protecting administrative state” means that the operator has issued a command switching the user traffic to the “protection” path. So, the current definition cannot cover the case where the operator has issued a MS-W command requesting to switch the user traffic to the “working” path. By replacing “Protecting administrative state” by “Switching administrative state”, it can cover both cases.

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.  
[Taesik] I think that this comment is not for the authors of the draft.

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. 
[Taesik] MS-W is already expanded in both Abstract and Section 1 of the draft. For MS-P, it can be expanded in both Abstract and Section 1 in the next revision of the draft. But, before doing this, we need to agree on the renaming because there is another review's comment not supporting this renaming.

Best regards,
Mach

> To: Eric Osborne (eosborne); Eric Gray; [email-masked]; 
> Yaacov Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); 
> Henderickx, Wim (Wim); [email-masked]; [email-masked]
> [email-masked]; 
> [email-masked]; VIGOUREUX, MARTIN (MARTIN)
> You been selected as MPLS-RT reviewers for a set of psc document that 
> we will start progress through the mpls working group.
> 
> 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 
> 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.
>

---

From: 정태식 <[email-masked]>
Date: Wed, 28 Aug 2013 00:10:19 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Yaacov Weingarten
Sent: Friday, August 23, 2013 3:56 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Minor comment:

Best regards,
Mach

> From: Loa Andersson [mailto:[email-masked]<mailto:[email-masked]>]
> To: Eric Osborne (eosborne); Eric Gray; [email-masked]<mailto:[email-masked]>; Yaacov
> (Wim); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
> Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

--
Thanx and BR,
yaacov

Still looking for new opportunity

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 28 Aug 2013 13:02:33 +0300

Taesik, hi

Thank you for your reply to my comments. While I appreciate the philosophy
that is behind the proposed format for this draft - and that some of your
considerations (for example, your need to change the name of Manual Switch
- something that would not be needed if you just wrote an update that
introduced the new operator command) are a direct result of this philosophy.

However, I found one of your replies to be of special interest.
On Wed, Aug 28, 2013 at 3:10 AM, 정태식 <[email-masked]> wrote:

>  Hi Yaacov,****
> ** **
> <trimmed content>
> ** **
> 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).
>

<<yw>> When I first read this draft I was under the impression that (as
impied by the title of the draft) the main justification for introducing
the MS-W command was to solve the problem of reverting traffic from a
non-revertive state and returning to the Normal State. However, according
to this explanation, using this command does not return you to the Normal
State, but rather to some intermediate state, since you are
"administartively controlled"!

So can you please explain how does the operator revert from the
non-revertive situation to the Normal State? (Is it a sequence of MS-W and
then immediately Clear? If so, why is this different from LO and immediate
Clear?)

> ****
> ** **
> <trimmed content>
Thanx and BR,
yaacov

---

From: 정태식 <[email-masked]>
Date: Wed, 28 Aug 2013 11:37:01 +0000

Hi Yaacov,

I answered to your question. Please see [Taesik2] inline.

Best regards,
Taesik

From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Wednesday, August 28, 2013 7:03 PM
To: 정태식
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Taesik, hi

Thank you for your reply to my comments. While I appreciate the philosophy that is behind the proposed format for this draft - and that some of your considerations (for example, your need to change the name of Manual Switch - something that would not be needed if you just wrote an update that introduced the new operator command) are a direct result of this philosophy.

However, I found one of your replies to be of special interest.
On Wed, Aug 28, 2013 at 3:10 AM, 정태식 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaacov,

<trimmed content>

<<yw>> When I first read this draft I was under the impression that (as impied by the title of the draft) the main justification for introducing the MS-W command was to solve the problem of reverting traffic from a non-revertive state and returning to the Normal State. However, according to this explanation, using this command does not return you to the Normal State, but rather to some intermediate state, since you are "administartively controlled"!

So can you please explain how does the operator revert from the non-revertive situation to the Normal State? (Is it a sequence of MS-W and then immediately Clear? If so, why is this different from LO and immediate Clear?)

[Taesik2] If you issue LO, you cannot protect traffic when SF or SD is subsequently detected on the working path until the LO is cleared. On the other hand, if you use MS-W, traffic can be protected because the priority of MS-W is lower than SF or SD.

<trimmed content>

--
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 28 Aug 2013 15:17:37 +0300

Hi,

Sorry for being insistent - you answered the secondary question but not the
primary question - if this is supposed to be for purposes of reversion from
a DNR state, why do we need the intermediary state? I would think it better
to not be administratively controlled and revert to Normal State!

BR,
yaacov

On Wed, Aug 28, 2013 at 2:37 PM, 정태식 <[email-masked]> wrote:

>  Hi Yaacov,****
>
> ** **
>
> I answered to your question. Please see [Taesik2] inline.****
>
> ** **
>
> Best regards,****
>
> Taesik****
>
> ** **
>
> *From:* Yaacov Weingarten [mailto:[email-masked]]
> *Sent:* Wednesday, August 28, 2013 7:03 PM
> *To:* 정태식
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
>
> *Subject:* Re: [mpls] MPLS-RT review on
> draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc
> documents****
>
> ** **
>
> Taesik, hi****
>
>  ****
>
> However, I found one of your replies to be of special interest. ****
>
> On Wed, Aug 28, 2013 at 3:10 AM, 정태식 <[email-masked]> wrote:****
>
> Hi Yaacov,****
>
>  ****
>
> <trimmed content>****
>
>  ****
>
> protection path (by MS-P).****
>
>  ****
>
> "administartively controlled"!  ****
>
>  ****
>
> Clear?)****
> [Taesik2] If you issue LO, you cannot protect traffic when SF or SD is
> subsequently detected on the working path until the LO is cleared. On the
> other hand, if you use MS-W, traffic can be protected because the priority
> of MS-W is lower than SF or SD.****
>
>    ****
>
> <trimmed content>****
>
>
> -- ****
>
>  Thanx and BR,****
>
> yaacov****
>
> ** **
>
> *Still looking for new opportunity*****
>

-- 
Thanx and BR,
yaacov

---

From: 정태식 <[email-masked]>
Date: Thu, 29 Aug 2013 08:54:26 +0000

Hi Yaacov,

Your question is not clear to me.
Before answering your question, could you please clarify following two sentences, especially for those marked with << >>?
- why do we need the <intermediary> state?
- it better to <not be administratively controlled> and <revert to Normal State>!

Best regards,
Taesik

From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Wednesday, August 28, 2013 9:18 PM
To: 정태식
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Hi,

Sorry for being insistent - you answered the secondary question but not the primary question - if this is supposed to be for purposes of reversion from a DNR state, why do we need the intermediary state? I would think it better to not be administratively controlled and revert to Normal State!

BR,
yaacov

On Wed, Aug 28, 2013 at 2:37 PM, 정태식 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaacov,

Best regards,
Taesik

From: Yaacov Weingarten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 28, 2013 7:03 PM
To: 정태식
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Taesik, hi

<trimmed content>

<trimmed content>

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 29 Aug 2013 12:17:56 +0300

Hi,

1. In your reply to my review comment - you explained that after issuing
the MS-W command even though the traffic is being transported on the
working path it is in "Administartive Switching State" because it is
"administratively" controlled - so I think that you need to explain what is
meant by "administratively controlled".

2. Regarding the other terms - not sure what is not clear. If the traffic
is on the protection path (either as a result of a SF [in RFC6378] or
operator command [according to your proposal]) and the system is in
non-revertive state. When the switching trigger clears, the traffic remains
on the protection path and the system goes into DNR state. Your proposal
(at least according to my original understanding) was to introduce a
command that would allow the operator to cancel the DNR and revert to
Normal State. However, I now understand that this is not the case - but
instead by issuing the MS-W command the system goes into an intermediary
state, i.e. Administratively Switching State, instead of going back to
Normal State.

Therefore, my question was:
1. Why do we need this Administrative Switching State, why not go directly
(i.e. revert) to Normal State?
2. What is the sequence of commands/operations/triggers that returns the
system to Normal State from DNR state?

Hope this clarifies,
yaacov

On Thu, Aug 29, 2013 at 11:54 AM, 정태식 <[email-masked]> wrote:

>  Hi Yaacov,****
>
> ** **
>
> Your question is not clear to me. ****
>
> Before answering your question, could you please clarify following two
> sentences, especially for those marked with << >>?****
>
> - why do we need the <intermediary> state?****
>
> - it better to <not be administratively controlled> and <revert to Normal
> State>!****
>
> ** **
>
> Best regards,****
>
> Taesik****
>
> ** **
>
> *Sent:* Wednesday, August 28, 2013 9:18 PM
> *To:* 정태식
>
> Hi,****
> Sorry for being insistent - you answered the secondary question but not
> the primary question - if this is supposed to be for purposes of reversion
> from a DNR state, why do we need the intermediary state? I would think it
> better to not be administratively controlled and revert to Normal State!**
> **
>
>  ****
>
> BR,****
>
> yaacov****
>
> ** **
>
> On Wed, Aug 28, 2013 at 2:37 PM, 정태식 <[email-masked]> wrote:****
>
> Hi Yaacov,****
>
>  ****
>
> [email-masked]****
>
>
> 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).****
>
>  ****
>

-- 
Thanx and BR,
yaacov

---

From: 정태식 <[email-masked]>
Date: Fri, 30 Aug 2013 01:18:10 +0000

Hi Yaacov,

Please see [Taesik] inline.

Best regards,
Taesik

From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Thursday, August 29, 2013 6:18 PM
To: 정태식
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Hi,

1. In your reply to my review comment - you explained that after issuing the MS-W command even though the traffic is being transported on the working path it is in "Administartive Switching State" because it is "administratively" controlled - so I think that you need to explain what is meant by "administratively controlled".
[Taesik] “Protecting administrative State” means that traffic is “administratively controlled” to flow on the protection path. “Switching administrative state” means that the traffic is “administratively controlled” to flow on the protection path in case of FS or MS(-P), or on the working path in case of MS-W.

2. Regarding the other terms - not sure what is not clear. If the traffic is on the protection path (either as a result of a SF [in RFC6378] or operator command [according to your proposal]) and the system is in non-revertive state. When the switching trigger clears, the traffic remains on the protection path and the system goes into DNR state. Your proposal (at least according to my original understanding) was to introduce a command that would allow the operator to cancel the DNR and revert to Normal State. However, I now understand that this is not the case - but instead by issuing the MS-W command the system goes into an intermediary state, i.e. Administratively Switching State, instead of going back to Normal State.
[Taesik] FS, MS(-P) and MS-W are all same in the sense that traffic is controlled by an operator. If I follow your logic, any state changed by an external command can be viewed as an intermediary state until that command is cleared. But, I don’t want to consider it as an intermediary state.

Therefore, my question was:
1. Why do we need this Administrative Switching State, why not go directly (i.e. revert) to Normal State?
[Taesik] The Correct name proposed in this draft is “Switching Administrative State”. “Protecting Administrative State” is already there. This draft proposes to rename it to cover MS-W as well as FS and MS(-P).
[Taesik] If you change PSC state machine, you can do anything. This draft does not propose something new, but proposes to add an external command (MS-W) which has been identified in liaisons between ITU-T and IETF that it is missing from RFC6378.

2. What is the sequence of commands/operations/triggers that returns the system to Normal State from DNR state?
[Taesik] Just issue MS-W, and then clear it at any time (when you want to go to Normal).

Hope this clarifies,
yaacov

On Thu, Aug 29, 2013 at 11:54 AM, 정태식 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yaacov,

Best regards,
Taesik

Hi,

BR,
yaacov

Best regards,
Taesik

Taesik, hi

<trimmed content>

<trimmed content>

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Fri, 30 Aug 2013 02:37:41 +0000

Yaacov,

If we want to cancel the DNR and revert to Normal state, we cannot use a "Cancel/Clear DNR" command directly.

Let's assume such a clear DNR command exists.
1. If the clear command is issued at node A in DNR state, then node A will enter Normal state and generate NR messages.
2. When node Z receives the NR message in DNR state, it will ignore the NR from node A according to the current PSC state machine in RFC6378. And node Z keeps sending DNR message.
3. When node A receives the DNR message, it will be ignored according to the current PSC state machine in RFC6378.
4. Now, the reversion to Normal state fails. Moreover, we have out of service situation as node A's bridge and selector are pointing the working path and node B's bridge and selector are point the protection path.

In the other protection switching technology, such as ITU-T's APS, there is no one-shot clear command that can clear DNR state and revert directly to Normal or "No request" state.

So the sequence of MS-W followed by Clear MS-W will do the job correctly.
Here, we cannot use MS-P instead of MS-W, as clearing MS-P will result in entering the DNR state again.

If this is not an answer for your question, please let me know.

Best regards,

Jeong-dong

________________________________
From : "Yaacov Weingarten" <[email-masked]>
Sent : 2013-08-29 18:18:17 ( +09:00 )
To : 정태식 <[email-masked]>
Cc : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject : Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents

Hi,

Hope this clarifies,
yaacov

Best regards,
Taesik

Hi,

BR,
yaacov

Best regards,
Taesik

Taesik, hi

<trimmed content>

<trimmed content>

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov