Subject: Last call on Protection and Restoration Design Team drafts

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Mar 2004 11:23:38 -0000

As discussed in the CCAMP meeting today, the Protection and Restoration Design Team drafts
have been around and stable for a long time.

The terminology draft (draft-ietf-ccamp-gmpls-recovery-terminology-03.txt) is marked as
standards track, but clearly does not require an implementation.

The Functional Analysis draft (draft-ietf-ccamp-gmpls-recovery-functional-01.txt) is
neither marked as informational nor standards track - perhaps the editors would like to
fix this as a last call comment. Nevertheless, this is clearly not aimed at having an
implementation.

The Recovery Analysis draft (draft-ietf-ccamp-gmpls-recovery-analysis-02.txt) is
informational and does not need an implementation.

This email begins a working group last call on
draft-ietf-ccamp-gmpls-recovery-terminology-03.txt,
draft-ietf-ccamp-gmpls-recovery-functional-01.txt and
draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

The last call will end on Friday 26th March at 12 noon GMT.

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-02.txt

Comments to the list or to the chairs direct.
Thanks,
Adrian

---

From: "Richard Rabbat" <[email-masked]>
Date: Sun, 14 Mar 2004 17:37:20 -0800

Yes to all,
Richard.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: Thursday, March 04, 2004 3:24 AM
> To: [email-masked]
> Subject: Last call on Protection and Restoration Design Team drafts
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Mar 2004 14:50:04 +0100

Editors,

WG last call has completed on this draft.

A few comments were received. Please address these in a new version and submit it so that
I can pass the draft on to the ADs.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Mar 2004 17:48:43 +0100

Editors,

Working group last call has completed on this draft without any further comments (that I
saw).

I have a few nits that I'd like you to fix and then we can pass the draft on to the ADs.

Thanks,
Adrian
============

Contributors
Please update contact details

Please add a list of Contents

Section 1 - non-ASCII characters
Unless otherwise stated, all references to ôlinkö in this draft

2. Span Protection
Please left justify heading

Section 2
   set of M protection links, usually cwith M <= N.
Read "with".

Section 2 - missing line break
   set of M protection links, usually cwith M <= N. A failure in any of    the N working
links results in traffic being switched to one of the

2.1 Unidirectional 1+1 dedicated protection
Please left justify heading

Section 2.1
        ôDedicated 1+1ö along with the bandwidth parameters for the
Non-ASCII characters

Section 2.1
        using the Link Management Protocol (LMP), or if LMP is not
Please add reference for LMP (and in other places in the draft).

Section 2.2
   Suppose an LSP is routed over link i between two nodes A and B.
Please state "a bi-directional LSP"

   2.3 Dedicated 1:1 protection with Extra Traffic
Please left justify heading

Section 2.3
   of the nodes, A or B. This node is referred to as the ômasterö. The    other node is
called the ôslaveö. The determination of the master    and the slave may be based on
configured information or protocol
Non-ASCII characters (two places)

Section 2.3 - missing line break
   of the nodes, A or B. This node is referred to as the ômasterö. The    other node is
called the ôslaveö. The determination of the master    and the slave may be based on
configured information or protocol

Section 2.3
            Traffic(i.e.,the traffic is dropped by the slave and not
Insert space "Traffic (i.e."

Section 2.3
Please add text to introduce the bullets beginning...
          o Pre-emption MUST be supported to accommodate Extra
             Traffic.

2.6 Messages
You say that these messages MUST be transmitted reliably.
You must, therefore, say what action is taken when such a
message fails to be delivered.

3.0 End-to-End (Path) Protection and Restoration
Read "3. End-to-End..."

Section 3.
   tend protection schemes and the functional steps needed to implement
Read "to-end"

Section 3.2
          o Switchover: The action when an end node detects a failure
See my comments on the terminology draft. This usage is consistent with what I would like
to see (namely "switchover"), but is inconsistent with the current terminology draft.

Section 3.2
                                  At the same time, send a switchover
             request message to the other end node to enable switching
             at the other end.
There is no subject of this sentence.
Ditto in the subsequent bullet.

3.1 Unidirectional 1+1 Protection
In the bi-directional case you point out that there are two distinct
failure detection cases. The case of detection by an intermediate
node gives rise to the requirement for signaling with an End-to-End
Failure Indication Message.
Why is this not a requirement in the unidirectional case?

Section 3.2.1
You don't say (but I know you have discovered in the solution draft)
that there is a correlation requirement between working and protection
LSP Identifiers. As you go on to place requirements on nodal information
in the next section, it would be worth clarifying the requirements on
LSP Identifiers.

Section 3.2.2
   Each node that is on the working or protection path of an LSP must
   have knowledge of the LSP identifier as well as the previous and
   next nodes in the LSP. This is so that restoration-related messages
   may be forwarded properly.
I don't see this requirement for end-to-end restoration.
It would appear only to be the case that *some* forwarding mechanism exists.

3.2.4  End-to-End Failure Acknowledge Message
   This message is sent by the source node in response to an End-to-End
   failure indication message. This message is sent to the originator
   of the failure indication message. The acknowledge message should be
   sent for each failure indication message received.  Each
   intermediate node receiving the acknowledge message must forward it
   towards the destination of the message.
It is not clear from this text what the purpose of this message is. If it is solely to
acknowledge the End-to-End Failure Indication Message, then you need to add a caveat that
this message need not be used when either
- some other means of reliable delivery of the Failure Message is used
or
- some other means of failure indication is used.

3.2.6  End-to-End Switchover Response Message
Please make it clear that this message may convey a positive or negative outcome.

Section 3.3
   signaling draft describes different type of switches [GMPLS_SIG]).
Read "[GMPLS-SIG]"

3.3.1  End-to-End Failure Indication and Acknowledgement
As per 3.2.3 and 3.2.4, you need to clarify that there is no requirement that these
messages flow along the path of the LSP.
As per my comment for 3.2.4, you need to clarify the purpose of the Acknowledgement
message.

Section 3.3
Nowhere in this section do you describe how the resources of the broken primary LSP may
become available for use by other LSPs (extra traffic or shared mesh protection) once the
traffic has been switched off the primary (but not necessarily before it has been switched
onto the protection LSP).

Section 4
   working path remains allocated to the LSP that was originally routed
   over it even after a failure. It is
   important to have mechanisms that allow reversion to be performed
   with minimal service disruption to the customer. This can be
   achieved using a ôbridge-and-switchö approach (often referred to as
make-before-break).

   The basic steps involved in bridge-and-switch are:

     1. The source node commences the process by ôbridgingö the signal         onto both
the working and the protection paths (or links in the
        case of span protection).
Line under-flow
Non-ASCII characters
Line over-flow
Line over-flow

Section 4
     5. Upon receipt of this message, the destination stops
        transmitting along the protection path and de-activates the LSP
        along this path. The de-activation procedure should remove the
        cross-LSPs along the protection path (and frees the resources
        to be used for restoring other failures.
For "cross-LSP" read "cross-connections"?

Section 4
   to force a switchover (from working to protect or vice versa), and
Read "protection"

Section 4
   working to protect administratively. These administrative conditions
Ditto

Security Considerations
It would be appropriate to write some material on the consequences to
security of protection schemes. For example, the consequences of badly
applied protection may increase the risk of misconnection. In particular
when extra traffic is involved, it is easily possible to deliver the
wrong traffic to the wrong place.
Similarly, an intrusion that sets up what appears to be a valid
protection LSP and then causes a fault may be able to divert traffic.
It is the place of this type of draft to guide the security behavior of
the solutions drafts that will follow.

6. Author's Addresses
Read "Authors' Addresses"
Update as required

7. Intellectual Property Considerations
Please use new boilerplate

Copyright
Please use the new boilerplate.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Mar 2004 20:42:51 +0100

Editors,

Working Group last call has completed on this draft without further comments (that I saw).

I have a few nits that I would like you to fix and then we can pass the draft on to the
ADs.

Thanks,
Adrian
============

1. Table of Content
Please don't number the table of contents
(See below for why this is good news :-)

Section 2
   Conventions used in this document:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

   Any other recovery-related terminology used in this document
   conforms to the one defined in [TERM]. The reader is also assumed to
   be familiar with the terminology developed in [GMPLS-ARCH], [RFC-
   3471], [RFC-3473], [GMPLS-RTG] and [LMP].
This material should be in its own section not lumped in with "Contributors"

Section 3.
   IETF CCAMP Working Group. Here, the focus will only be on transport
For "will only be" read "is only"

Section 3.
   In the present release, a detailed analysis is provided for each of
Strike "In the present release,"

Section 4.1
   the transport plane, the latter, upon failure condition, MUST
Read "upon a failure"

Section 4.1
     defect û excessive errors (EXC) or degraded signal (DEG) - is
Non-ASCII character

Section 4.2
   consuming failure isolation (see also Section 4.5). This is
There is no section 4.5

Section 5.4
   In both schemes, it results a "group" of sum{n=1}^N N{n} working
Read "results in a"

Section 5.4
   one working LSP to be denied automatic recovery. But if one consider
Read "considers"

Section 5.5.1
   LSPs/spans recovery time and ratio depend on the proper recovery LSP
   provisioning (meaning pre-provisioning when performed before failure
   occurrence) and the level of recovery resources overbooking (i.e.
   over-provisioning). A proper balance of these two operations will
Rephrase
   The recovery time and ratio of LSPs/spans depend on proper recovery LSP
   provisioning (meaning pre-provisioning when performed before failure
   occurrence) and the level of overbooking of recovery resources (i.e.
   over-provisioning). A proper balance of these two operations will

Section 5.5.1
   classified here below to structure the analysis of the different
Strike "here"

Section 5.5.1
   options can be classified (as shown in the below figure) as follows:
Read "in the figure below"

Section 5.5.1
   (3) when the recovery resources are pre-reserved, they can be either
       pre-selected or selected on-demand.
I think people may find it hard to understand how a resource can be pre-reserved when it
has not yet been selected.
Can you clarify this.
In fact, it might be helpful in this section to clarify the behavioral differences when
resources are overbookable (such as in PSC) and when resources are synonymous to labels.

6. Normalization
[TERM] uses the term "reversion" and only peripherally mentions "normalization"
And, indeed, you revert to the word "reversion" in section 6.2

Section 7
   desirable to avoid that similar layers with functional overlaps to
Strike "that"

Section 7.2
   - Potentially, recovery capabilities with different temporal
Read "Potential recovery"

Section 7.2
   Here below we briefly extend on (4), (2) being covered in [RFC
   3386]. On the other hand (1) is extensively covered at the MPLS
   Working Group, and (3) at the PWE3 Working Group.
Read
   Below we briefly expand on (4) only. (2) is covered in [RFC-
   3386]. (1) is extensively covered by the MPLS
   Working Group, and (3) by the PWE3 Working Group.

Section 7.2
   Note: Recovery Granularity
Read
7.2.1 Recovery Granularity

Section 7.4.1
   A Shared Risk Link Group (SRLG) is defined as the set of optical
   spans (or links or optical lines) sharing a common physical resource
   (for instance, fiber links, fiber trunks or cables) i.e. sharing a
   common risk.
Why do you limit this to optical spans in this way? Would it not be better to describe
this in terms of physical or logical networking resources?
But, in any case, shouldn't you really refer to the definition elsewhere? It is not in
[TERM] (perhaps it should be), but the definition in [CCAMP-SRLG] should be good enough.
You go on to describe a link belonging to an SRLG. Do you mean TE link?

Section 7.4.1
   (but not a sufficient) condition to ensure optical network
Again, not sure why you are limited to optical networks.

Section 8.4.1
   The knowledge of this information available per TE link can be
   exploited in order to optimize the usage of the resources allocated
   per TE link for shared recovery. If one refers to r[i] as the actual
   bandwidth per TE link i (in terms of discrete bandwidth units)
   committed for shared recovery, then the following quantity must be
   maximized over the potential TE link candidates: sum {i=1}^N [(R{i}
   - r{i})/(t{i} û b{i})] or equivalently: sum {i=1}^N [(R{i} -
   r{i})/r{i}] with R{i} >= 1 and r{i} >= 1 (in terms of per component
   bandwidth unit). In this formula, N is the total number of links
   traversed by a given LSP, t[i] the Maximum Link Bandwidth per TE
   link i and b[i] the sum per TE link i of the bandwidth committed for
   working LSPs and other recovery LSPs (thus except "shared bandwidth"
   LSPs). The quantity [(R{i} - r{i})/r{i}] is defined as the Shared
   (Recovery) Bandwidth Ratio per TE link i. In addition, TE links for
   which R[i] reaches max_R[i] or for which r[i] = 0 are pruned during
   shared recovery path computation as well as TE links for which
   max_R[i] = r[i] which can simply not be shared.
Could you check the formulae. Do you really mean square root b{i} ? Regardless, this is a
non-standard ASCII character.
Could you also break the text so each formula is presented whole on a separate line.

Section 9
It would be nice to give a one-line key for each of the three path setup mechanisms (1, 2
and 3) in the table.

10. Security Considerations
Do all of the protection and recovery mechanisms described have identical security
implications? If so, please add that statement.
If not (which I suspect) please add some text to compare and contrast the security of the
different techniques.

Please use new IPR boilerplate

References
Could you check that [IPO-IMP], [CCAMP-LI], [CCAMP-SRLG], [MPLS-OSU] and [TE-NS] have not
died?
The version numbers and dates of references are (of course) a little out of date.

14. Author's Addresses
Read "Editors' Addresses" ?

Please use new copyright boilerplate.