Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

From: Jeong Ryoo <[email-masked]>
Date: Fri, 4 Jul 2014 00:52:50 +0000

Dear Lou,

Thanks a lot for your valuable comments.

The authors of this draft have discussed your comments, and are proposing our resolutions to your comments. Please, let us know if the proposal is appropriate to address your comments and concerns.

Best regards,

Authors of draft-ietf-mpls-smp-requirements draft

****** Beginning of Comment Resolution ******

- Document's usage of "committed" vs "allocated" resources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protection path
but not the earlier "allocation" of resources. (Quoted terms are
used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be replaced
with terminology used in the referenced RFCs, i.e., "allocation",
"connection", "cross-connect", "protection switch(over)", ...

Note I'm *not* highlighting all cases where there are problems in the
document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

[Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we concluded that the distinction between protection and restoration should be aligned with the exiting documents normatively referenced by this document. Accordingly, the following 16 modifications will be done in revision:

(1) Section 1, the third paragraph
OLD:
As pointed out
in [RFC6372] and [RFC4428], applying 1+1 linear protection requires
that resources are committed for use by both the working and
protection paths. Applying 1:1 protection requires that the same
resources are committed, but allows the resources of the protection
path to be utilized for pre-emptible extra traffic.
NEW:
As pointed out
in [RFC6372] and [RFC4428], applying 1+1 protection requires
that resources are allocated for use by both the working and
protection paths. Applying 1:1 protection requires that the same
resources are allocated, but allows the resources of the protection
path to be utilized for pre-emptible extra traffic.

(2) The whole text in Section 3.1 will be replaced with:
[RFC6372], based upon the definitions in [RFC4427], differentiates between "protection" and "restoration" dependent upon the dynamism of the resource allocation. The same distinction is used in [RFC3945], [RFC4426], and [RFC4428]. This document also uses the same distinction between protection and restoration as stated in [RFC6372].

(3) In page 6,
OLD:
The use of preemption in the network is typically a business or
policy decision such that when protection resources are contended,
priority can be applied to determine to which parties the protection
resources are committed.
NEW:
The use of preemption in the network is typically a business or
policy decision such that when protection resources are contended,
priority can be applied to determine which parties utilize the protection
resources.

(4) Page 7, the first paragraph:
OLD:
the resources for the protection path are fully committed,
NEW
the resources for the protection path are fully dedicated,

OLD:
resources may be planned but would not be committed until …
NEW:
resources may be planned but would not be utilized until …

(5) In the second paragraph in page 7,
OLD:
"Hard Preemption" requires the programming of selectors at the ingress of each shared segment to specify which backup path has the highest priority when committing protection resources, the others being preempted.
NEW
"Hard Preemption" requires the programming of selectors at the ingress of each shared segment to specify the priorities of backup paths, so that traffic of lower priority paths can be preempted.

(6) The first paragraph of Section 4.1:
OLD:
… and commit the associated resources. The commitment of resources
is dependent upon …
NEW:
… and coordinate the utilization of the associated shared resources.
The resource utilization coordination is dependent upon …

(7) The second paragraph of Section 4.1:
OLD:
When the reserved resources of the shared segments are committed to a
particular protection path, there may not be sufficient resources
available for an additional protection path. This then implies that
if another working path of the SMP domain triggers a protection
switch, the commitment of the resources may fail. In order to
optimize the operation of the commitment and preparing for cases of
multiple working paths failing, the commitment of the shared
resources are be coordinated between the different working paths in
the SMP network.
NEW:
When the reserved resources of the shared segments are utilized by a
particular protection path, there may not be sufficient resources
available for an additional protection path. This then implies that
if another working path of the SMP domain triggers a protection
switch, the resource utilization coordination may fail. The different working paths in
the SMP network are involved in the resource utilization coordination.
.

(8) Section 5.1,
OLD:
… and commit the associated resources.
NEW
… and coordinate the utilization of the associated shared resources.

(9) In Section 5.1,
OLD:
In the case of multiple working paths failing, the commitment of the
shared resources SHALL be coordinated between the different working
paths in the SMP network.
NEW:
In the case of multiple working paths failing, the shared resource utilization
coordination SHALL be between the different working
paths in the SMP network.

(10) Section 5.1.1.
OLD:
… because they already have been committed to the protection of, for example, a higher priority working path.
NEW:
… because they already have been utilized for the protection of, for example, a higher priority working path.

(11) Section 5.2, the second bullet item:
OLD:
Resources of the shared segments SHALL be committed to the
protection path …
NEW:
Resources of the shared segments SHALL be utilized by the
protection path …

(12) Section 5.2, the third bullet item:
OLD:
If multiple protection paths of equal priority are requesting
allocation of the shared resources, the resources SHOULD be
committed on a first come first served basis.
NEW:
If multiple protection paths of equal priority are requesting
the shared resources, the resources SHOULD be
assigned on a first come first served basis.

(13) Section 5.2, the fourth bullet item:
OLD:
If the protection resources are committed to a protection path,
whose working path has a lower priority, resources required for
the higher priority path SHALL be committed to the higher priority
path.
NEW:
If the protection resources are utilized by a protection path,
whose working path has a lower priority, resources required for
the higher priority path SHALL be assigned to the higher priority
path.

(14) Section 5.2. the seventh bullet item
OLD:
Once resources of shared segments have been successfully committed
to a protection path, …
NEW:
Once resources of shared segments have been successfully utilized
by a protection path, …

(15) Section 5.3, the first paragraph,
OLD:
… request the commitment of protection resources. If the necessary
shared resources are unavailable to be committed to the protection
path, the endpoints …

NEW:
… request the coordination of the shared resource utilization. If the necessary
shared resources are unavailable, the endpoints …

(16) Section 5.3, the second paragraph,
OLD:
Similarly, if preemption is supported and the resources currently
committed for a particular working path are …
NEW:
Similarly, if preemption is supported and the resources currently
utilized by a particular working path are …

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions
to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this in
the abstract and move it to a more pronounced place in section 1 (or
3).

[Authors] We can add the following paragraph at the end of Section 1:
“This document is intended to clarify the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.”

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

[Authors] Fate-sharing is not required by this document. Even in the PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-routing, either.

- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

[Authors] One concern is that RFC 6372 describes both soft and hard preemptions in the context of extra traffic, which is not exactly the case for SMP.

- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

[Authors] Yes, we will make the correction.

- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover
mechanism is used, the control plane SHALL NOT ...". If referring to
an operator's/user's choice of protection mechanism, I think the most
you can say is MAY.

[Authors] The first case is the one we are aiming at. We will use SHALL NOT.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking
rules" should be defined directly or by reference.

[Authors] The sentence can be rewritten as:
OLD:
Tie-breaking rules SHALL be defined in scope of an SMP domain.
NEW:
In order to cover the situation where the first come first served principle cannot resolve the contention among multiple equal priority requests, i.e., when the requests occur simultaneously,, tie-breaking rules SHALL be defined in scope of an SMP domain.

- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

[Authors] We can add the following sentence at the end:
“As described in [RFC6372], the event of preemption may be detected by OAM and reported as a fault or a degradation of traffic delivery.”

- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

[Authors] Yes, we will change the second paragraph from “SMP in hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the changed paragraph above the first paragraph.

Nits:

- Abstract: I don't recall the term "executive action" being used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

[Authors] Yes, the term will be changed as you suggested.

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

[Authors] The proposed text for the paragraph 1 is:
“The MPLS Transport Profile (MPLS-TP) is described in [RFC5921],
and [RFC6372] provides a survivability framework for MPLS-TP
and is the foundation for this document.”

- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

[Authors] OK.

- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

[Authors] Section 3 was intended to present a reference model for SMP. Some text of Section 2 is repeated in Section 1 as you suggested earlier.

- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

[Authors] [RFC4206] will be added as a reference

- Section 3.2 again uses the "executive action" term.

[Authors] OK, the term will be changed.

- Section 4.1. You say "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

[Authors] Both actions should occur at the same time, or as closely as possible to provide fast protection.

- Section 5.2. I suggest numbering the currently bulletted requirements
list.

[Authors] OK, we will use numbers.

- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

[Authors] The first paragraph is for soft-preemption, while the fourth bullet belongs to the requirements of hard-preemption.

- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

[Authors] Yes, req 5 can be moved to Section 5.5.

- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

[Authors] Yes, it will be deleted.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

[Authors] Req. 9 will be deleted as it seems to require control plane supports.

- Section 5.3. s/MAY/will

[Authors] OK.

- section 5.4: " When the working path detects.." detection is by the
node not the path.

[Authors] Yes. We will simply say that “When the condition that triggered the protection switching is cleared, …”

- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

[Authors] As in other protection switching technologies, two modes of operations (revertive and non-revertive) are required.

- section 5.6. RFC 6372 should be referenced
[Authors] We will add “as described in [RFC6372]” to the ends of two paragraphs for WTR timer and hold-off timer.

***** End of Comment resolution *****

________________________________
보낸 사람 : "Lou Berger" <[email-masked]>
보낸 날짜 : 2014-06-22 01:00:48 ( +09:00 )
받는 사람 : [email-masked] <[email-masked]>
참조 : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
제목 : [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the
Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-mpls-smp-requirements-06.txt
Reviewer: Lou Berger
Review Date: June 21 2014
IETF LC End Date: 2014-06-23
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think
should (must, actually) be resolved before publication.

Comments:

I think the document is well written and, other than a couple of
terminology related issues, easily understood. The document does
have a number of terminology and technical issues which should be
readily resolved prior to publication.

Major Issues:

Major issues are the type of concerns that will result in the
document being blocked until they are resolved. The Routing ADs will
become involved. Please include all of the major issues you have
found. Give as much context information as possible (e.g., section
numbers, paragraph counts). If you find no major issues, please
write: "No major issues found."

- No major issues found. In particular, I expect all issues can be
resolved without AD intervention. Some of the minor issues, if not
resolved will be escalated to the AD/major issue category.

Minor Issues:

Minor issues are concerns about clarity or technical accuracy that
should be discussed and resolved before publication, but which would
normally be resolved between the authors and the reviewers. Please
include all of the minor issues you have found. Give as much context
information as possible (e.g., section numbers, paragraph counts).
If you find no minor issues, please write: "No minor issues found."

- Document's usage of "committed" vs "allocated" resources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protection path
but not the earlier "allocation" of resources. (Quoted terms are
used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be replaced
with terminology used in the referenced RFCs, i.e., "allocation",
"connection", "cross-connect", "protection switch(over)", ...

Note I'm *not* highlighting all cases where there are problems in the
document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions
to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this in
the abstract and move it to a more pronounced place in section 1 (or
3).

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover
mechanism is used, the control plane SHALL NOT ...". If referring to
an operator's/user's choice of protection mechanism, I think the most
you can say is MAY.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking
rules" should be defined directly or by reference.

- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

Nits:

- Abstract: I don't recall the term "executive action" being used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

- Section 3.2 again uses the "executive action" term.

- Section 4.1. You say "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

- Section 5.2. I suggest numbering the currently bulletted requirements
list.

- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

- Section 5.3. s/MAY/will

- section 5.4: " When the working path detects.." detection is by the
node not the path.

- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

- section 5.6. RFC 6372 should be referenced

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Lou Berger <[email-masked]>
Date: Sat, 05 Jul 2014 11:26:06 -0400

Jeong/Authors,
    Thank you for the response.  Most of the changes look good.  I still
have a few questions and open comments.  Please see below.

Lou

On 7/3/2014 8:52 PM, Jeong Ryoo wrote:
> The authors of this draft have discussed your comments, and are
> proposing our resolutions to your comments. Please, let us know if the
> proposal is appropriate to address your comments and concerns.
>
>  
>
> Best regards,
>
>  
>
...
>
>  
>
> [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we
> concluded that the distinction between protection and restoration
> should be aligned with the exiting documents normatively referenced by
> this document. Accordingly, the following 16 modifications will be
> done in revision:
>
... (deleted changes looked fine.)
> the resources for the protection path are fully dedicated,
Dedicated is also an ambiguous term, how about:
OLD
   the resources for the protection path are fully committed, the
   protection path in the case of SMP consists of segments that are
   dedicated to the protection of the related working path and also
NEW
   the resources for the protection path are fully allocated, the
   protection path in the case of SMP consists of segments that are
   allocated to the protection of the related working path and also

> resources may be planned but would not be utilized until …
How about:
OLD
   resources may be planned but would not be committed until requested
NEW

   resources may be allocated but would not be utilized until requested

...
> the SMP network are involved in the resource utilization coordination. 

This is fine, but I wonder why you are using "resource utilization" vs
"protection switch"? (this is actually a bit of a general comment -- I
the latter is an existing applicable term that would help readers how
this document fits in to the technology space.)

...
> assigned on a first come first served basis.

why use a new term "assigned" vs the previous term "utilized"?  If there
is no distinction being made the same term should be used (either term
is fine, but choose one). If there is a distinction, it should be made
explicit (i.e., explained).

> the higher priority path SHALL be assigned to the higher priority
same comment.

...
> “This document is intended to clarify the instructions to protocol
> designers producing solutions that satisfy the requirements set out in
> this document.”
>
>  
>
>

How about being even more explicit (in both the abstract and section 1):
   This document provides requirements  for  any
   mechanism that would be used to implement SMP for MPLS-TP data paths,
   in networks that delegate protection switch coordination to the data
   plane.

> [Authors] Fate-sharing is not required by this document. Even in the
> PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271
> (PSC in APS mode), fate-sharing is not required as unidirectional
> switching is allowed. This document does not impose any restriction on
> co-routing, either.
>
>  
>

Both RFC4427 and 6372 mention this (Bi-directional recovery switching in
the former). I think this document really needs to mention something on
the topic.  Given the 6372 a "MAY" level requirement is probably
sufficient, but this should be confirmed with the WG.  (I personally
would like SHOULD as this seems to better match 6372's text "operator
often requires...".)

> [Authors] One concern is that RFC 6372 describes both soft and hard
> preemptions in the context of extra traffic, which is not exactly the
> case for SMP.
>

Then 6372 should be referenced and the difference should be described. 
Otherwise readers are likely to think you just used the wrong reference
and that 6372's text applies.  6372 is after all titled "MPLS-TP
Survivability Framework"...

> [Authors] Yes, we will make the correction.
okay
> [Authors] The first case is the one we are aiming at. We will use
okay.
> In order to cover the situation where the first come first served
> principle cannot resolve the contention among multiple equal priority
> requests, i.e., when the requests occur simultaneously,, tie-breaking
> rules SHALL be defined in scope of an SMP domain.
>
>  
>
>  
>

good enough (i.e., states that the definition of tie-breaking is FFS.)

> “As described in [RFC6372], the event of preemption may be detected by
> OAM and reported as a fault or a degradation of traffic delivery.” 
>

okay.
> [Authors] Yes, we will change the second paragraph from “SMP in
> hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the changed
> paragraph above the first paragraph.
>
>  
>
>
> Nits:
>
great.
> and is the foundation for this document.”
okay.
> [Authors] Section 3 was intended to present a reference model for SMP.
> Some text of Section 2 is repeated in Section 1 as you suggested earlier.
>
>  
>
We're in the domain of style, so is your call.
> possible to provide fast protection.
What text change is planned?

> [Authors] The first paragraph is for soft-preemption, while the fourth
> bullet belongs to the requirements of hard-preemption.
>

Do you plan a text change?  (the 1st paragraph should be a list item and
soft-preemption is mentioned as a parenthetical , and the forth doesn't
mention its scope as hard preemption.)

> [Authors] Yes, req 5 can be moved to Section 5.5.
okay.

> [Authors] Yes, it will be deleted.
great.
> [Authors] Yes. We will simply say that “When the condition that
> triggered the protection switching is cleared, …”
>
>
> [Authors] As in other protection switching technologies, two modes of
> operations (revertive and non-revertive) are required.
>
>  
>
>
> [Authors] We will add “as described in [RFC6372]” to the ends of two
> paragraphs for WTR timer and hold-off timer.
>
>  
>
Okay.

> ***** End of Comment resolution *****
...

---

From: Yaacov Weingarten <[email-masked]>
Date: Sat, 5 Jul 2014 22:49:10 +0300

Lou, hi
I would like to address two of your comments, in your follow-up message,
since I am the source of the change in terminology.

Regarding the two occurences of "assigned" in place of "utilized" - when I
read the proposed changes,as discussed amongst the authors, I felt that in
those two instances the use of "utilized" could lead to some ambiguity.

If we state that "resources SHOULD be utilized on a first come first served
basis" this could be interpreted (IMO) as referring to the packet level,
rather than  utilized by a specific path, such that packets from different
paths could be interspersed along the shared segments. Therefore,I
suggested that or this context it would be better to use a word that meant
that the first-come first served basis was at the level of assigning (or
allocating) the resources rather than utilizing them.

Hope this clarifies this point. I am certain that I speak for the other
authors in  saying that I am open to other suggestions.

BR,
yaacov
On Jul 4, 2014 3:53 AM, "Jeong Ryoo" <[email-masked]> wrote:

> The authors of this draft have discussed your comments, and are proposing
> our resolutions to your comments. Please, let us know if the proposal is
> appropriate to address your comments and concerns.
>
>
>
> Best regards,
>
>
>
> concluded that the distinction between protection and restoration should be
> aligned with the exiting documents normatively referenced by this document.
> Accordingly, the following 16 modifications will be done in revision:
>
>
>
> [RFC6372], based upon the definitions in [RFC4427], differentiates between
> "protection" and "restoration" dependent upon the dynamism of the resource
> allocation. The same distinction is used in [RFC3945], [RFC4426], and
> [RFC4428]. This document also uses the same distinction between protection
> and restoration as stated in [RFC6372].
>
>
>
> (3) In page 6,
>
> OLD:
>
> "Hard Preemption" requires the programming of selectors at the ingress of
> each shared segment to specify which backup path has the highest priority
> when committing protection resources, the others being preempted.
>
> NEW
>
> "Hard Preemption" requires the programming of selectors at the ingress of
> each shared segment to specify the priorities of backup paths, so that
> traffic of lower priority paths can be preempted.
>
>
>
> designers producing solutions that satisfy the requirements set out in this
> document.”
>
>
>
>
>  [Authors] Fate-sharing is not required by this document. Even in the PSC
> linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in
> APS mode), fate-sharing is not required as unidirectional switching is
> allowed. This document does not impose any restriction on co-routing,
> either.
>
>
>
>
> preemptions in the context of extra traffic, which is not exactly the case
> for SMP.
>
>
>
>
> “As described in [RFC6372], the event of preemption may be detected by OAM
> and reported as a fault or a degradation of traffic delivery.”
>
>
>  ------------------------------
> *보낸 사람 : *"Lou Berger" <[email-masked]>
> *보낸 날짜 : *2014-06-22 01:00:48 ( +09:00 )
> *받는 사람 : [email-masked] <[email-masked]>
> *참조 : [email-masked] <[email-masked]>,
> [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>
> *제목 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt
>
>
> Hello,
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 08 Jul 2014 06:56:08 -0400

Yaacov,
    Sounds reasonable, but I'll need to see the new wording to be sure.

Thanks,
Lou
On 7/5/2014 3:49 PM, Yaacov Weingarten wrote:
>
> Lou, hi
> I would like to address two of your comments, in your follow-up
> message, since I am the source of the change in terminology.
>
> Regarding the two occurences of "assigned" in place of "utilized" -
> when I read the proposed changes,as discussed amongst the authors, I
> felt that in those two instances the use of "utilized" could lead to
> some ambiguity.
>
> If we state that "resources SHOULD be utilized on a first come first
> served basis" this could be interpreted (IMO) as referring to the
> packet level, rather than  utilized by a specific path, such that
> packets from different paths could be interspersed along the shared
> segments. Therefore,I suggested that or this context it would be
> better to use a word that meant that the first-come first served basis
> was at the level of assigning (or allocating) the resources rather
> than utilizing them.
>
> Hope this clarifies this point. I am certain that I speak for the
> other authors in  saying that I am open to other suggestions.
>
> BR,
> yaacov
>
> On Jul 4, 2014 3:53 AM, "Jeong Ryoo" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear Lou,
>
>      
>
>     proposing our resolutions to your comments. Please, let us know if
>     the proposal is appropriate to address your comments and concerns.
>
>      
>
>     Best regards,
>
>      
>
>     [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428,
>     we concluded that the distinction between protection and
>     restoration should be aligned with the exiting documents
>     normatively referenced by this document. Accordingly, the
>     following 16 modifications will be done in revision:
>
>      
>
>     [RFC6372], based upon the definitions in [RFC4427], differentiates
>     between "protection" and "restoration" dependent upon the dynamism
>     of the resource allocation. The same distinction is used in
>     [RFC3945], [RFC4426], and [RFC4428]. This document also uses the
>     same distinction between protection and restoration as stated in
>     [RFC6372].
>
>      
>
>     (3) In page 6,
>
>     OLD:
>
>     "Hard Preemption" requires the programming of selectors at the
>     ingress of each shared segment to specify which backup path has
>     the highest priority when committing protection resources, the
>     others being preempted.
>
>     NEW
>
>     "Hard Preemption" requires the programming of selectors at the
>     ingress of each shared segment to specify the priorities of backup
>     paths, so that traffic of lower priority paths can be preempted.
>
>      
>
>     … because they already have been committed to the protection of,
>     for example, a higher priority working path.
>
>     NEW:
>
>     … because they already have been utilized for the protection of,
>     for example, a higher priority working path.
>
>      
>
>     designers producing solutions that satisfy the requirements set
>     out in this document.”
>
>      
>
>
>     [Authors] Fate-sharing is not required by this document. Even in
>     the PSC linear protection switching, such as RFC 6378 (PSC) and
>     RFC 7271 (PSC in APS mode), fate-sharing is not required as
>     unidirectional switching is allowed. This document does not impose
>     any restriction on co-routing, either.
>
>      
>
>
>     [Authors] One concern is that RFC 6372 describes both soft and
>     hard preemptions in the context of extra traffic, which is not
>     exactly the case for SMP.
>
>      
>
>
>     principle cannot resolve the contention among multiple equal
>     priority requests, i.e., when the requests occur simultaneously,,
>     tie-breaking rules SHALL be defined in scope of an SMP domain.
>
>      
>
>      
>
>
>     “As described in [RFC6372], the event of preemption may be
>     detected by OAM and reported as a fault or a degradation of
>     traffic delivery.” 
>
>
>     hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the
>     changed paragraph above the first paragraph.
>
>      
>
>
>     Nits:
>
>     [Authors] Section 3 was intended to present a reference model for
>     SMP. Some text of Section 2 is repeated in Section 1 as you
>     suggested earlier.
>
>      
>
>      
>
>
>     [Authors] Both actions should occur at the same time, or as
>     closely as possible to provide fast protection.
>
>      
>
>
>     [Authors] The first paragraph is for soft-preemption, while the
>     fourth bullet belongs to the requirements of hard-preemption.
>
>
>     [Authors] As in other protection switching technologies, two modes
>     of operations (revertive and non-revertive) are required.
>
>      
>
>
>     [Authors] We will add “as described in [RFC6372]” to the ends of
>     two paragraphs for WTR timer and hold-off timer.
>
>      
>
>     ------------------------------------------------------------------------
>     *보낸 사람 : *"Lou Berger" <[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]>
>     <[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]>

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Jul 2014 07:55:39 -0400

Jeong-dong,
Thank you for the response, see below.

On 7/10/2014 2:55 AM, 류정동 wrote:
>
> Thank you, Lou
>
> Please, see the lines starting with [JR] for my responses to your
comments.
>
> I removed the parts that we have already agreed on. I also erased your
comments that are minor editorial and will be reflected in the next
version as you suggested. The two “assigned” related comments are not
covered here as they are being discussed with Yaacov.
> Jeong-dong
> ******
> [JR] This paragraph describes the difference between linear protection
and shared mesh protection from the perspective of protection resource
sharing. In linear protection switching, the resources are not shared
but dedicated to the protection path. SMP has shared resources in some
segments. I think the word, “dedicated” is general enough to be used
without any further definition. RFC 6372 also uses “dedicated“, and this
document follows the same use as in RFC 6372

I think the (new) first usage of dedicated in paragraph is fine, it's
the second I have a real issue with.  I suggested changing both to avoid
the term altogether.  The way "dedicated" is used in the second sentence
is in the context of SMP, while RFC6372 uses "dedicated"  the context of
"Dedicated Protection" which is contrasted with "Shared Protection".
How about:

NEW
   the resources for the protection path are fully dedicated, the
   protection path in the case of SMP consists of segments that are
   used for protection of the related working path and also

>
> [JR] As described in an earlier part of this section, SMP protection
consists of two operations: traffic switchover and resource utilization
coordination. The sentences are about the resource utilization
coordination, and “resource utilization” seems to be more accurate.

Is "resource utilization coordination" done via some form of inter-node
coordination? If yes, then I think my comment holds.  If no, then I
think you should elabotate on how the "coordination" in this case
differes from how you use "coordination" elsewhere in the document.
Either way, I think we've discussed this enough, i.e., I won't push this
point further.

>
>
> Both RFC4427 and 6372 mention this (Bi-directional recovery switching
in the former). I think this document really needs to mention something
on the topic.  Given the 6372 a "MAY" level requirement is probably
sufficient, but this should be confirmed with the WG.  (I personally
would like SHOULD as this seems to better match 6372's text "operator
often requires...".)
>
> [JR] O.K. I guess that mandating bidirectional switching does not mean
that unidirectional switching is prohibited. What we can do is that,
after changing the title of Section 5.4. from “Revertive protection
switching” to “Reversion and Fate-sharing”, one paragraph with the
following sentence will be added: “Bidirectional protection switching
SHOULD be supported in SMP.”

The topics are essentially orthognal, i.e., supporting one without the
other is completly reasonable.  If you don't want to add a dedicated
section, then Sections 5.7, 5.3 and perhaps even 5.5 are better choices.

>
> [JR] O.K. 6372 will be referenced and we can add the following
sentence as the third sentence in the paragraph: “The traffic of lower
priority paths in this document can be viewed as the extra traffic being
preempted in [RFC6372].”

great.

> [JR] We can erase “simultaneously” and add the sentence (“Both
operations should occur at the same time, or as closely as possible to
provide fast protection.”) as the second sentence of the paragraph.

WFM.

>
> Do you plan a text change?  (the 1st paragraph should be a list item
and soft-preemption is mentioned as a parenthetical , and the forth
doesn't mention its scope as hard preemption.)
>
> [JR] OK. We can make them clear. How about the following arrangement?
>
> 5.2. Multiple triggers
>
> If more than one working path is triggering a protection switch such
> that a protection segment is oversubscribed, there are two different
> actions that the SMP network can choose – soft preemption and hard
> preemption.
>
> 5.2.1. Soft-preemption
>
> For networks that support multiplexing packets over the shared
segments, the requirement is:
>
> O All of the protection paths MAY be allowed to share the resources
> of the shared segments
>
> 5.2.2 Hard-preemption
>
> There are networks that require the exclusive use of the protection
> resources when a protection segment is oversubscribed.
> Traffic of lower priority paths is completely blocked.
> These include networks that support the requirements in [RFC5654],
> and in particular support requirement 58. For such networks,
> the following requirements apply:
>
> O ...
>
> O ...
>

I think this will work.

Thanks,
Lou

...

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Jul 2014 08:09:41 -0400

[Got some odd bounces on my 1st attempt to send this...]

Jeong-dong,

comments.
comments that are minor editorial and will be reflected in the next
version as you suggested. The two âassignedâ related comments are not
covered here as they are being discussed with Yaacov.
and shared mesh protection from the perspective of protection resource
sharing. In linear protection switching, the resources are not shared
but dedicated to the protection path. SMP has shared resources in some
segments. I think the word, âdedicatedâ is general enough to be used
without any further definition. RFC 6372 also uses âdedicatedâ, and this
document follows the same use as in RFC 6372

NEW

consists of two operations: traffic switchover and resource utilization
coordination. The sentences are about the resource utilization
coordination, and âresource utilizationâ seems to be more accurate.

that unidirectional switching is prohibited. What we can do is that,
after changing the title of Section 5.4. from âRevertive protection
switchingâ to âReversion and Fate-sharingâ, one paragraph with the
following sentence will be added: âBidirectional protection switching
SHOULD be supported in SMP.â

> [JR] O.K. 6372 will be referenced and we can add the following
sentence as the third sentence in the paragraph: âThe traffic of lower
priority paths in this document can be viewed as the extra traffic being
preempted in [RFC6372].â

great.

> [JR] We can erase âsimultaneouslyâ and add the sentence (âBoth
operations should occur at the same time, or as closely as possible to
provide fast protection.â) as the second sentence of the paragraph.

WFM.

> actions that the SMP network can choose â soft preemption and hard
> preemption.
>
> 5.2.1. Soft-preemption
>

I think this will work.

Thanks,
Lou

...

---

From: 류정동 <[email-masked]>
Date: Thu, 10 Jul 2014 06:55:03 +0000

Thank you, Lou

Please, see the lines starting with [JR] for my responses to your comments. 

I removed the parts that we have already agreed on. I also erased your comments that are minor editorial and will be reflected in the next version as you suggested. The two “assigned” related comments are not covered here as they are being discussed with Yaacov. 

Best regards,

Jeong-dong

****** 

[JR] This paragraph describes the difference between linear protection and shared mesh protection from the perspective of protection resource sharing. In linear protection switching, the resources are not shared but dedicated to the protection path. SMP has shared resources in some segments. I think the word, “dedicated” is general enough to be used without any further definition. RFC 6372 also uses “dedicated“, and this document follows the same use as in RFC 6372

This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.)

[JR] As described in an earlier part of this section, SMP protection consists of two operations: traffic switchover and resource utilization coordination. The sentences are about the resource utilization coordination, and “resource utilization” seems to be more accurate. 

Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic.  Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG.  (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".)

[JR] O.K. I guess that mandating bidirectional switching does not mean that unidirectional switching is prohibited. What we can do is that, after changing the title of Section 5.4. from “Revertive protection switching” to “Reversion and Fate-sharing”, one paragraph with the following sentence will be added: “Bidirectional protection switching SHOULD be supported in SMP.”     

Then 6372 should be referenced and the difference should be described.  Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies.  6372 is after all titled "MPLS-TP Survivability Framework"...

[JR] O.K. 6372 will be referenced and we can add the following sentence as the third sentence in the paragraph: “The traffic of lower priority paths in this document can be viewed as the extra traffic being preempted in [RFC6372].”  

[JR] We can erase “simultaneously” and add the sentence (“Both operations should occur at the same time, or as closely as possible to provide fast protection.”) as the second sentence of the paragraph.

Do you plan a text change?  (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.)

5.2. Multiple triggers

5.2.1. Soft-preemption

For networks that support multiplexing packets over the shared segments, the requirement is:

5.2.2 Hard-preemption

O ...

O ...

*****

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 6일 일요일 오전 12:26
받는 사람: 류정동; [email-masked]
참조: [email-masked]; [email-masked]; [email-masked]
제목: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong/Authors,
    Thank you for the response.  Most of the changes look good.  I still have a few questions and open comments.  Please see below.

Lou

Best regards,

...

OLD:

...

This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.)

...

why use a new term "assigned" vs the previous term "utilized"?  If there is no distinction being made the same term should be used (either term is fine, but choose one). If there is a distinction, it should be made explicit (i.e., explained).

same comment.

...

Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic.  Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG.  (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".)

Then 6372 should be referenced and the difference should be described.  Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies.  6372 is after all titled "MPLS-TP Survivability Framework"...

okay.

okay.

Nits:

great.

okay.

[Authors] OK.

Do you plan a text change?  (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.)

okay.

great.

[Authors] OK.

Okay.

---

From: 류정동 <[email-masked]>
Date: Thu, 10 Jul 2014 07:52:02 +0000

Lou and Yaacov,

Here is my suggestion on those two bullet item texts related to "assigned".

As in my earlier email to Lou's followup comments, 
we can make two sub sections under this Section 5.2. 
and title them as "5.2.1 Soft preemption" and "5.2.2 Hard preemption". 
Those two bullet items with "assigned" will be placed under 5.2.2 Hard preemption.

In addition to this, we can clarify further, so that "utilized" is not being misused.
New texts for those two bullet items are:

o If multiple protection paths of equal priority are requesting
   the shared resources, the resources SHALL be
   utilized on a first come first served basis. 
   Traffic of the protection paths that request the shared resource late 
   SHALL be blocked or MAY use available resource without interrupting 
   traffic of prior protection paths that are utilizing the shared resource.
   In order to cover the situation where the first come first served principle 
   cannot resolve the contention among multiple equal priority requests, 
   i.e., when the requests occur simultaneously, tie-breaking rules 
   SHALL be defined in scope of an SMP domain.

o If a higher priority path requires the protection resources that are
   being utilized by a lower priority path, the resources SHALL be
   utilized by the higher priority path.   
   Traffic with the lower priority SHALL be blocked or MAY use available resources 
   without interrupting traffic of the higher priority path.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 8일 화요일 오후 7:56
받는 사람: Yaacov Weingarten; 류정동
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Yaacov,

Thanks,
Lou

---

From: 류정동 <[email-masked]>
Date: Thu, 10 Jul 2014 13:43:31 +0000

Lou,

Thank you for agreeing on most of the suggestions.
Please, see the lines starting with [JR2] below.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 10일 목요일 오후 8:55
받는 사람: 류정동
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: 회신: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong-dong,

comments.

NEW

[JR2] I am ok with your proposed text.

[JR2] "resource utilization coorination" occurs between the nodes as in other protection switching. "resource utilization coordination" is a part of whole SMP protection switching coordination and is meant to emphasize that coordination is for resource utilization. Of course, the reason why it does resource utilization coordination is to complete protection switching eventually. 

[JR2] Yes, I also think that those sections that you suggested can be good candidates to accommodate "fate-sharing".
I just picked up 5.4 because it currently has just one paragraph and might be easiler to parse the section if two paragraphs are there. And, revertive/non-revertive (mode of operation) and uni-/bi-directional switching (type of switching) are often used together to characterize the protection switching process running on a protected domain. 

great.

WFM.

I think this will work.

Thanks,
Lou

...

---

From: 류정동 <[email-masked]>
Date: Thu, 10 Jul 2014 14:01:13 +0000

Lou,

They are meant to be under the hard-preemption.
And, you are right. They are no good. 
(I just tried to keep what have been there before.)

New suggestions: 
======
   SHALL be blocked.

o If a higher priority path requires the protection resources that are
   being utilized by a lower priority path, the resources SHALL be
   utilized by the higher priority path.
   Traffic with the lower priority SHALL be blocked. 
======

Yaacov and co-authors:
See if new texts are ok.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 10일 목요일 오후 9:04
받는 사람: 류정동; Yaacov Weingarten
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: 회신: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong-dong,

Did you perhaps mean that these new paragraphs would be under the
soft-preemption section? If so, sounds fine. If not, allowing use of
available resources by the "hard-peempted" traffic runs counter to RFC6372:

- In "hard preemption", the extra traffic is excluded from the
protection resource. The disruption of the extra traffic is total,
and the service supported by the extra traffic must be dropped, or
some form of rerouting or restoration must be applied to the extra
traffic LSP in order to recover the service.

...

- In "soft preemption", the extra traffic is not explicitly excluded
from the protection resource, but is given lower priority than the
protected traffic. In a packet network (such as MPLS-TP), this can
result in oversubscription of the protection resource with the
result that the extra traffic receives "best-effort" delivery.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 11 Jul 2014 15:09:59 -0400

Thank you -- just one response and suggested change.

Lou

...
> [JR2] "resource utilization coorination" occurs between the nodes as in other protection switching. "resource utilization coordination" is a part of whole SMP protection switching coordination and…

Okay. I think adding something along the lines of ""resource utilization
coordination" is a part of whole SMP protection switching coordination "
to the text would clarify your intent to future readers.
...

---

From: 류정동 <[email-masked]>
Date: Fri, 11 Jul 2014 20:44:05 +0000

Lou, 

Certainly, it can be done as you suggested.
I also think that your suggested change would help the readibility of this document.
Thanks a lot for your help.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 12일 토요일 오전 4:09
받는 사람: 류정동
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: [RTG-DIR] 회신: 회신:  [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Lou

...

---

From: 류정동 <[email-masked]>
Date: Fri, 11 Jul 2014 20:45:31 +0000

Lou, 

I have no problem with changing as you suggested.
Again, thanks for your help.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 12일 토요일 오전 4:12
받는 사람: 류정동; Yaacov Weingarten
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: [RTG-DIR] 회신: 회신:  [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong-dong,
        One tweak and we're there!
Given preemption is already defined, how about:
s/blocked/preempted.

Lou

---

From: 류정동 <[email-masked]>
Date: Fri, 11 Jul 2014 21:00:05 +0000

Lou, 

I sent the previous email without showing the proposed text. 
The last sentence of the last paragraph in Section 4.1 will be:
------
When the reserved resources of the shared segments are utilized by 
a particular protection path, there may not be sufficient resources
available for an additional protection path. This then implies that
if another working path of the SMP domain triggers a protection
switch, the resource utilization coordination may fail.
The different working paths in the SMP network are involved in the resource 
utilization coordination, which is a part of whole SMP protection switching coordination.
------
Please, let me know if there is someting to improve.

Best regards,

Jeong-dong

________________________________________
보낸 사람: 류정동
보낸 날짜: 2014년 7월 12일 토요일 오전 5:44
받는 사람: Lou Berger
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: 회신: [RTG-DIR] 회신: 회신:  [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Lou,

Best regards,

Jeong-dong

Lou

...

---

From: Lou Berger <[email-masked]>
Date: Mon, 14 Jul 2014 11:24:26 -0400

Jeong-dong,

Unless I missed something, I think we've closed all topics. Agreed?

Much thanks,
Lou

---

From: Jeong Ryoo <[email-masked]>
Date: Tue, 15 Jul 2014 00:56:02 +0000

Lou,

My record says the same. Many thanks for your review and helpful comments.
I will reflect all the resolutions to a revision and post in public soon.

Best regards,

Jeong-dong

________________________________
보낸 사람 : "Lou Berger" <[email-masked]>
보낸 날짜 : 2014-07-15 00:24:41 ( +09:00 )
받는 사람 : 류정동 <[email-masked]>
참조 : [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
제목 : Re: [RTG-DIR] 회신: 회신: 회신: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong-dong,

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jul 2014 08:05:16 -0400

Yaacov, Jeong,
    I'm not sure how the latest text addresses the ambiguity you
identified below.  Perhaps adding the words "on a per LSP basis" to the
requirement?  If the ambiguity is intentional, then of course no change
is warranted.

Lou

---

From: 류정동 <[email-masked]>
Date: Thu, 24 Jul 2014 11:52:37 +0000

Lou,

Any ambiguity is not intentional.

The latest text related to this issue is:
--- 
   3. If multiple protection paths of equal priority are requesting the
      shared resources, the resources SHALL be utilized on a first come
      first served basis. Traffic of the protection paths that request
      the shared resources late SHALL be preempted. In order to cover
      the situation where the first come first served principle cannot
      resolve the contention among multiple equal priority requests,
      i.e., when the requests occur simultaneously, tie-breaking rules
      SHALL be defined in scope of an SMP domain.

   4. If a higher priority path requires the protection resources that
      are being utilized by a lower priority path, the resources SHALL
      be utilized by the higher priority path. Traffic with the lower
      priority SHALL be preempted.
---

The text is already saying that the preepmtion and utilization is per path basis. 
In my opinion, it seems to be ok without adding an LSP here.

Jeong-dong

보낸 날짜: 2014년 7월 23일 수요일 오후 9:05

Yaacov, Jeong,

Lou

---

From: 류정동 <[email-masked]>
Date: Thu, 24 Jul 2014 21:08:35 +0000

Lou,

The text in the current draft (07 version) was reviewed by Yaacov before uploading in public.
He might have some nits that can be fixed during the RFC editing, 
but  it is my understanding that he is ok with the current one.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 25일 금요일 오전 5:23
받는 사람: 류정동; Yaacov Weingarten
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: [RTG-DIR] 회신:  [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

I believe the ambiguity mentioned by Yacov still exists. I actually
defer to Yacov on this, and if he's happy with the text -- so am I.

Lou

PS I have a couple of more minor comments to send -- and will do so as
soon as I can.

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Jul 2014 07:48:27 -0400

Jeong,
    I think the document looks good.  Two *minor* comments on the latest
rev:
 
> priority paths in this document can be viewed as the extra traffic being

Section 4 looks good, but the reference is missing from in 5.2.

>    Bidirectional protection switching SHOULD be supported in SMP.

This is really in the wrong section.  bidirectional PS has nothing to do
with reversion.  As before, I think section 5.7 is the best place for it.

Lou

---

From: 류정동 <[email-masked]>
Date: Fri, 25 Jul 2014 13:26:50 +0000

Lou,

Thanks for the comments.
As you suggested, RFC 6372 is added in Section 5.2 
and the sentence on bidirectional switching is moved to Section 5.7.

I am uploading a revision.

Again, thanks for your thorogh review.

Best regards,

Jeong-dong

________________________________________
보낸 사람: Lou Berger [[email-masked]]
보낸 날짜: 2014년 7월 25일 금요일 오후 8:48
받는 사람: 류정동
참조: [email-masked]; [email-masked]; [email-masked]; [email-masked]
제목: Re: [mpls] 회신: [RTG-DIR]  RtgDir review: draft-ietf-mpls-smp-requirements-06.txt

Jeong,

Lou