Subject: [mpls-tp] Comments of draft-ietf-mpls-tp-survive-fwk-04

From: "Daniele Ceccarelli" <[email-masked]>
Date: Fri, 2 Apr 2010 16:11:33 +0200

Dear Nurit and Adrian,

Please find some comments on the survivability framework draft. Some of
them are just clarification requests.

- Abstract - Paragraph 3
   Detailed consideration for the protection of
   pseudowires in MPLS-TP networks is out of scope.

  I would substitute "protection" with "recovery" (as per what stated in
RFC 4427 and later in this ID, the term recovery includes both
protection and restoration)

-  Introduction - Paragraph 1
   degradation of traffic delivery
   caused by a network fault or an attack on the network;
  What do you mean by "attack on the network"? Denial of service? 

- Introduction - Paragraph 1
    Same comment as before. You use the term "restore" while "recover"
could be more appropriate.

- 1.1 Recovery schemes
   Maybe it is worth spending one sentence also on pre-emption
priorities just after the recovery priorities.

- 1.2 Recovery Action Initiation - Paragraph 1
   recovery actions in the data plane
   and are equally applicable in MPLS-TP with or without the use of a
   control plane.
  How can restoration be performed without a control plane.

- 1.3 Recovery Context
   An MPLS-TP LSP may be subject to any or all of MPLS-TP link recovery,
   path segment recovery, or end-to-end recovery, where:

   RFC 4427 speaks about span recovery instead of link recovery. Also,
in the following of this ID (section 4) the term span is used instead of
link and you say: 
   A span is sometimes incorrectly referred to as a
   link, and this may cause some confusion between the concept of a data
   link and a traffic engineering (TE) link.
   I think it worth using everywhere in the text the term "span" instead
of "link"

- 1.4 Scope of this Framework - Paragraph 1
   Just a typo comment: There is an open bracket that is not closed.

- 1.4 Scope of this Framework - Paragraph 7
   Another typo comment:
     The greater the level of
   protection, the greater the number of resources consumed and so the
   higher the likely cost both to the operator and to the customer.
 
  There should be a verb somewhere :)

- 2 Terminology and references
   It could be useful to add a further bulle defining what
"survivability actions" are. (term widely usend in the following of the
text)

- 3. Requirements for survivabiliy
   I agree with Stewart's comment in his AD review. In my opinion a
pointer to RFC5654 is enough. Also because a future change in RFC5654
will require a modification also of this ID.

- 3. Requirements for survivabiliy - Paragraph 1
   serve as a
   normative reference for the definition of all MPLS-TP function
   including survivability
     An "s" is missing in "function"

- 3.1 General requirements - Last paragraph
   Note that there is no requirement for support for extra traffic
   [RFC4427] except in a ring where MPLS-TP must support the sharing of
   protection bandwidth in a ring by allowing best-effort traffic (108).
   This form of extra traffic may sometimes referred to as "non-
   preemptable unprotected traffic".
    It is not clear to me why the best-effort traffic using the
protection bandwidth is non-preemptable. It the protected LSP fails, the
protection bandwidth is used and so this "kind of extra-traffic" must be
pre-empted. 

- 4.1 Elemntest of control
   Type comment: "or may be under direct the control of an operator
   Maybe you mean: or may be under the direct control of an operator

- 4.1.1 Manual control
    Bullets: consider adding a fourth bullet with force reversion or
just add "and viceversa" at the end of bullet 3

- 4.1.4 - Control plane signaling
   Control plane signaling is responsible for setup, maintenance, and
  teardown of transport paths...
  I would mention also lps ownership handover from MP to CP and
viceversa

- 4.3.4 Restoration - Paragraph 3
   Typo: s/low/lower

- 4.3.5 Reversion - paragraph 4
   Which is a suggested default value for the WTR timer?

- 4.5 Recovery domains - Paragraph 5
   Typo: Note that a single link may "be" part of several recovery
domains.

Best regards
Daniele

 <<Picture (Device Independent Bitmap)>>  

DANIELE CECCARELLI  
System & Technology - DU IP & Broadband 

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750
[email-masked]
www.ericsson.com  

 <http://www.ericsson.com/>  <<Picture (Device Independent Bitmap)>>   

This Communication is Confidential. We only send and receive email on
the basis of the term set out at www.ericsson.com/email_disclaimer

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Apr 2010 22:14:04 +0100

Got it, thanks.

Hope to be working on updates this week and will respond as necessary.

A
----- Original Message ----- 
From: "Daniele Ceccarelli" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 02, 2010 3:11 PM
Subject: [mpls-tp] Comments of draft-ietf-mpls-tp-survive-fwk-04

Dear Nurit and Adrian,

- Abstract - Paragraph 3

- 1.1 Recovery schemes

- 1.3 Recovery Context

- 4.1.1 Manual control

Best regards
Daniele

DANIELE CECCARELLI

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750

--------------------------------------------------------------------------------

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

---

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

Hi Daniele,

Thanks for the comments.

> protection and restoration)

OK

>  What do you mean by "attack on the network"? Denial of service?

Yes. Words added.

>  could be more appropriate.

OK

> priorities just after the recovery priorities.

OK

 > How can restoration be performed without a control plane.

Using the management plane.
That is, the network issue is reported to the NMS, the NMS provisions a 
restoration LSP, and the traffic is enabled onto the new LSP.

>   I think it worth using everywhere in the text the term "span" instead

I agree with you. But unfortunately the consensus of the WG and the ITU-T 
during work on the requirements and other frameworks was to use the term 
link. For example, see R105 in RFC 5654.

I think we chose our words as carefully as possible, but would be happy to 
hear your suggestions to polish the text.

>   Just a typo comment: There is an open bracket that is not closed.

Yes

>  There should be a verb somewhere :)

Yeah. We will buy a sack of verbs and scatter them around.

> "survivability actions" are. (term widely usend in the following of the

OK

> will require a modification also of this ID.

Agreed per email back to Stewart.

>     An "s" is missing in "function"

Obsoleted by previous point.

> protection bandwidth is used and so this "kind of extra-traffic" must be

Obsoleted by previous.

>   Maybe you mean: or may be under the direct control of an operator

Fixed

> just add "and viceversa" at the end of bullet 3

OK

>  I would mention also lps ownership handover from MP to CP and

I think this part of maintenance.

> - 4.3.4 Restoration - Paragraph 3

OK

>   Which is a suggested default value for the WTR timer?

Interesting question.
I think this is not in scope for a framework.
It depends completely on deployment scenarios and operator objectives.

Is it possible to select a single default timer that works for all 
operational situations? I doubt it, but am happy to discuss.

>   Typo: Note that a single link may "be" part of several recovery

Yup

Many thanks,
Adrian and Nurit