Subject: [mpls-tp] Last Call comments on draft-ietf-mpls-tp-survive-fwk

From: Eric Gray <[email-masked]>
Date: Fri, 2 Apr 2010 11:55:36 -0400

Nurit/Adrian,

    Thanks for producing this very well written draft!

    Some last call comments on this draft:

1) Is there an intent that protection of multi-segment pseudowires will be discussed in
    a different survivability framework draft (currently, the draft says that it will be covered
    in a separate document - see section 7 - but does not indicate if this work is already
    underway, or even on the PWE3 charter)?  Multi-segment pseudowires would probably
    not be protected in all cases via use of protected LSPs, and protection of pseudowires
    is listed as a requirement in other framework and requirements drafts/RFCs.  It is worth
    pointing out that this document does a rather good job of covering the issues at a level
    I would expect from a framework document (it is not clear what missing details there
    are that would be appropriate at the framework level).  Perhaps it would be better to say
    that this document provides an essential framework-level discussion of PW protection
    issues, but that further detail is expected to be provided in PW protection documents
    to be produced by the PWE3 working group?  Right now, the wording seems to imply
    the existence of a hole that I am not sure really exists

2) In the final paragraph of the introduction, I believe the phrase you want to use is "packet
    based transport network" as opposed to "packet transport network"; the existing phrase
    effectively accentuates the confusion inherent in different interpretations of "transport"

3) In the first paragraph of section 1.1 ("Recovery Schemes"), I am not sure what "within
    the agreed service level" means; I believe a "service level agreement" is an agreement
    at the service level, but that what is agreed is a set of service parameters - suggesting
    that this should be "within the agreed service parameters"

4) in section 1.2 "control plane-driven actions" is hyphenated incorrectly (I assume the
    intent is that this refers to actions driven by the control plane, not control actions that
    are driven around in an airplane)

5) section 1.3 seems to be missing "node recovery" (which should probably be included
    between link recovery and segment recovery) - is this deliberate? (Note: I believe this
    is cleared up in the first paragraph of section 4.2.2, where it explains what is meant by
    "segment" in this context; I don't believe this is made clear before this point, perhaps
    it would help to provide a forward reference? The term "segment" is overloaded, even in
    the context of this draft, because of inclusion of multi-segment pseudowires as part of
    sections 4.2.2 and 7.1 and it does not help that in 1.3, it refers to "path segment" as
    opposed to LSP segment)

6) in the fifth paragraph of section 1.4, "races" should probably be "race conditions"

7) in the sixth paragraph of section 1.4, "affected traffic is recovered" would be better as
    "affected services are recovered" (general note: in several places, "traffic" is used as if
    "traffic" and "services" are synonymous; if this is intentional, is this explicitly stated
    somewhere and - if it is not intentional - should this be corrected generally?)

8) in the final sentence in section 1.4, "it is possible" should be "it should be possible"

9) section 4.6.1 goes to a header-depth level of 5 (4.6.1.1.1, 4.6.1.1.2 and 4.6.1.1.3), yet
    the ToC only supports headers to level 3; as a result, section 4.6.1 (which includes a
    total of 6 or 7 subsections) covers 8 pages in the ToC.  This makes some important
    work a little harder to find.  I suggest either re-structuring, or allowing for greater ToC
    depth

10) in section 6.4.3, "determining" should be "determine" (first line of text in section)

11) in section 6.4.4, "should be able fault conditions" should be "should be able to report
    fault conditions" (first line of text in section); "the network management" should either
    be "network management", or "the network management system" (two places in the
    second paragraph)

12) in section 6.5.5, "in needed" should be "is needed" (first line, second paragraph)

13) in section 6.5.6, "more simple" should be "simpler" (first line, second paragraph),
    "sub case" should be "special case" (first line on page 51) and "allows one LSP"
    should be "allows an LSP" (second bullet, on page 51)

14) in section 7.2, "actioned" should be "acted on" (third line, second paragraph)
[http://www.ericsson.com/shared/images/Email_line.gif]

ERIC GRAY

Ericsson
Systems and Technology
Phone +1 978 275 7470
Fax +1 978 275 7474
SMS/MMS +1 603 781 6751
[email-masked]
www.ericsson.com

[http://www.ericsson.com/shared/images/Email.gif]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 20:47:37 +0100

Thanks Eric,

Will stir these into the pot for the revision we are working on and will get 
back to you with answers or to debate any issues.

Adrian
----- Original Message ----- 
From: "Eric Gray" <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 02, 2010 4:55 PM
Subject: Last Call comments on draft-ietf-mpls-tp-survive-fwk

Nurit/Adrian,

1) Is there an intent that protection of multi-segment pseudowires will be 
discussed in
    a different survivability framework draft (currently, the draft says 
that it will be covered
    in a separate document - see section 7 - but does not indicate if this 
work is already
    underway, or even on the PWE3 charter)?  Multi-segment pseudowires would 
probably
    not be protected in all cases via use of protected LSPs, and protection 
of pseudowires
    is listed as a requirement in other framework and requirements 
drafts/RFCs.  It is worth
    pointing out that this document does a rather good job of covering the 
issues at a level
    I would expect from a framework document (it is not clear what missing 
details there
    are that would be appropriate at the framework level).  Perhaps it would 
be better to say
    that this document provides an essential framework-level discussion of 
PW protection
    issues, but that further detail is expected to be provided in PW 
protection documents
    to be produced by the PWE3 working group?  Right now, the wording seems 
to imply
    the existence of a hole that I am not sure really exists

2) In the final paragraph of the introduction, I believe the phrase you want 
to use is "packet
    based transport network" as opposed to "packet transport network"; the 
existing phrase
    effectively accentuates the confusion inherent in different 
interpretations of "transport"

3) In the first paragraph of section 1.1 ("Recovery Schemes"), I am not sure 
what "within
    the agreed service level" means; I believe a "service level agreement" 
is an agreement
    at the service level, but that what is agreed is a set of service 
parameters - suggesting
    that this should be "within the agreed service parameters"

4) in section 1.2 "control plane-driven actions" is hyphenated incorrectly 
(I assume the
    intent is that this refers to actions driven by the control plane, not 
control actions that
    are driven around in an airplane)

5) section 1.3 seems to be missing "node recovery" (which should probably be 
included
    between link recovery and segment recovery) - is this deliberate? (Note: 
I believe this
    is cleared up in the first paragraph of section 4.2.2, where it explains 
what is meant by
    "segment" in this context; I don't believe this is made clear before 
this point, perhaps
    it would help to provide a forward reference? The term "segment" is 
overloaded, even in
    the context of this draft, because of inclusion of multi-segment 
pseudowires as part of
    sections 4.2.2 and 7.1 and it does not help that in 1.3, it refers to 
"path segment" as
    opposed to LSP segment)

6) in the fifth paragraph of section 1.4, "races" should probably be "race 
conditions"

7) in the sixth paragraph of section 1.4, "affected traffic is recovered" 
would be better as
    "affected services are recovered" (general note: in several places, 
"traffic" is used as if
    "traffic" and "services" are synonymous; if this is intentional, is this 
explicitly stated
    somewhere and - if it is not intentional - should this be corrected 
generally?)

8) in the final sentence in section 1.4, "it is possible" should be "it 
should be possible"

9) section 4.6.1 goes to a header-depth level of 5 (4.6.1.1.1, 4.6.1.1.2 and 
4.6.1.1.3), yet
    the ToC only supports headers to level 3; as a result, section 4.6.1 
(which includes a
    total of 6 or 7 subsections) covers 8 pages in the ToC.  This makes some 
important
    work a little harder to find.  I suggest either re-structuring, or 
allowing for greater ToC
    depth

10) in section 6.4.3, "determining" should be "determine" (first line of 
text in section)

11) in section 6.4.4, "should be able fault conditions" should be "should be 
able to report
    fault conditions" (first line of text in section); "the network 
management" should either
    be "network management", or "the network management system" (two places 
in the
    second paragraph)

12) in section 6.5.5, "in needed" should be "is needed" (first line, second 
paragraph)

13) in section 6.5.6, "more simple" should be "simpler" (first line, second 
paragraph),
    "sub case" should be "special case" (first line on page 51) and "allows 
one LSP"
    should be "allows an LSP" (second bullet, on page 51)

14) in section 7.2, "actioned" should be "acted on" (third line, second 
paragraph)
[http://www.ericsson.com/shared/images/Email_line.gif]

ERIC GRAY

Ericsson
Systems and Technology
Phone +1 978 275 7470
Fax +1 978 275 7474
SMS/MMS +1 603 781 6751
[email-masked]
www.ericsson.com

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Apr 2010 13:43:42 +0100

Hi Eric,

Thanks for your comments.

>  Thanks for producing this very well written draft!

You are very welcome :-)

>    the existence of a hole that I am not sure really exists

There are probably three things that need to happen:
1. Complete MS-PW work in PWE3
2. Start MS-PW protection work in PWE3
3. Write a framework for PW protection (maybe in the scope of MPLS-TP)

Nurit is proposing to start a draft for 3 sometime soon(ish).

> interpretations of "transport"

Good catch.

>    that this should be "within the agreed service parameters"

OK

>    are driven around in an airplane)

I am entirely unable to grok the use of hyphens in US English :-(
I tend to leave this to the RFC Editor (who speaks American) and only make a 
vague guess at what might be correct.
We will stick in the extra hyphens and let the editor strip them as she sees 
fit.

>    sections 4.2.2 and 7.1 and it does not help that in 1.3, it refers to 

Yes, "segment" is chronically overloaded. I think we had a "coming together" 
of:
- PW segments (PWE3)
- LSP segments (CCAMP)
in Ipswich that resulted in some normalisation in the context of MPLS-TP 
which is dissonant with GMPLS.

Anyway, "node recovery" is not something we can do! We can protect against 
node failure.

So, the best way to handle this is some clarification in 1.3 that "segment 
recovery" (which includes segment and concatenated segment) is used to 
protect against node failure.

> 6) in the fifth paragraph of section 1.4, "races" should probably be "race 

OK

>    somewhere and - if it is not intentional - should this be corrected 

OK

> 8) in the final sentence in section 1.4, "it is possible" should be "it 

OK

>    work a little harder to find.  I suggest either re-structuring, or 

Yeah, you're right. We have renumbered around 4.6.

> 10) in section 6.4.3, "determining" should be "determine" (first line of 

OK

>    be "network management", or "the network management system" (two places 

Yes

> 12) in section 6.5.5, "in needed" should be "is needed" (first line, 

OK

>    should be "allows an LSP" (second bullet, on page 51)

Have used "simplify"

> 14) in section 7.2, "actioned" should be "acted on" (third line, second 

Have used "...actions... are performed"

Thanks again,
Nurit and Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 14 Apr 2010 11:12:18 -0400

Adrian/Nurit,

	In this reply, it is not always clear what you're saying okay 
to (I added a few notes below, and snipped the rest), but it seems 
that many of my comments will be addressed.  I look forward to the 
new version...

--
Eric 

---[SNIP]---
>    discussed in a different survivability framework draft (currently, the 
>    draft says that it will be covered in a separate document - see section
>    7 - but does not indicate if this work is already underway, or even on
>    the PWE3 charter)?  Multi-segment pseudowires would probably not be
>    protected in all cases via use of protected LSPs, and protection of
>    pseudowires is listed as a requirement in other framework and
>    requirements drafts/RFCs.  It is worth pointing out that this document
>    does a rather good job of covering the issues at a level I would expect
>    from a framework document (it is not clear what missing details there
>    are that would be appropriate at the framework level).  Perhaps it
>    would be better to say that this document provides an essential 
>    framework-level discussion of PW protection issues, but that further
>    detail is expected to be provided in PW protection documents to be
>    produced by the PWE3 working group?  Right now, the wording seems to
>    imply the existence of a hole that I am not sure really exists

EG > does this mean that the wording will change?
=================================================

---[SNIP]---

>    would be better as "affected services are recovered" (general note: 
>    in several places, "traffic" is used as if "traffic" and "services"
>    are synonymous; if this is intentional, is this explicitly stated

OK

EG > Okay to the suggestion for section 1.4, or okay on the general note?
EG > If the latter, what do you expect to do about the general issue?
=========================================================================

OK

> 9) section 4.6.1 goes to a header-depth level of 5 (4.6.1.1.1, 4.6.1.1.2 
>    and 4.6.1.1.3), yet the ToC only supports headers to level 3; as a
>    result, section 4.6.1 (which includes a total of 6 or 7 subsections)
>    covers 8 pages in the ToC.  This makes some important work a little
>    harder to find.  I suggest either re-structuring, or allowing for
>    greater ToC depth

EG > Not sure what this means, but I look forward to the newer, improved,
EG > version...
=========================================================================

---[SNIP]---

> 13) in section 6.5.6, "more simple" should be "simpler" (first line, 
>     second paragraph), "sub case" should be "special case" (first line
>     on page 51) and "allows one LSP" should be "allows an LSP" (second
>     bullet, on page 51)

Have used "simplify"

EG > ?

EG > ?

Thanks again,
Nurit and Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Apr 2010 14:37:06 +0100

Hello Eric,

> that many of my comments will be addressed.

See inline for responses to your comments.

>    imply the existence of a hole that I am not sure really exists
|
| There are probably three things that need to happen:
| 1. Complete MS-PW work in PWE3
| 2. Start MS-PW protection work in PWE3
| 3. Write a framework for PW protection (maybe in the scope of MPLS-TP)
|
| Nurit is proposing to start a draft for 3 sometime soon(ish).

Yes; text change. The presence or absence of holes should be out of scope of 
this document.

>    somewhere and - if it is not intentional - should this be corrected
|
| OK
|

OK to the general point. We have gone through the document tuning toward 
"service" rather than "traffic" in the case where it means "service" but 
leaving traffic where we mean a collection of packets.

>    harder to find.  I suggest either re-structuring, or allowing for
|
|Yeah, you're right. We have renumbered around 4.6.
|
EG > Not sure what this means, but I look forward to the newer, improved,
EG > version...

We have broken stuff out into higher level sections and renumbered 
accordingly. This makes the sections more manageable and pushes more stuff 
into the ToC.

>     on page 51) and "allows one LSP" should be "allows an LSP" (second
|
| Have used "simplify"
EG > ?

OLD
   Several protocol extensions exist to make this process more simple:
NEW

> 14) in section 7.2, "actioned" should be "acted on" (third line, second
|
| Have used "...actions... are performed"
|
EG > ?

OLD

   As with any recovery mechanism, it is important to coordinate between
   layers.  This coordination is necessary to ensure that  recovery 
mechanisms are only actioned in one layer at a time (that is, the recovery 
of an underlying LSP needs to be coordinated with the recovery of the PW 
itself), and to make sure that the working and protection PWs do not both 
use the same MPLS resources within the network (for example, by running over 
the same LSP tunnel - compare with Section 4.6.2).
NEW

   As with any recovery mechanism, it is important to coordinate between
   layers.  This coordination is necessary to ensure that actions associated 
with recovery mechanisms are only performed in one layer at a time (that is, 
the recovery of an underlying LSP needs to be coordinated with the recovery 
of the PW itself); it also makes sure that the working and protection PWs do 
not both use the same MPLS resources within the network (for example, by 
running over the same LSP tunnel - see also Section 4.9).

Regards,
Adrian and Nurit

---

From: Eric Gray <[email-masked]>
Date: Fri, 16 Apr 2010 09:59:11 -0400

Adrian,

	Thanks!

--
Eric 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, April 16, 2010 9:37 AM
To: Eric Gray
Cc: [email-masked]
Subject: Re: Last Call comments on draft-ietf-mpls-tp-survive-fwk
Importance: High

Hello Eric,

|

|
| OK
|

|

|
| Have used "simplify"
EG > ?

OLD

|

OLD

Regards,
Adrian and Nurit