[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG Last Call on draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
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.
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Thursday, March 04, 2004 12:23 PM
Subject: Last call on Protection and Restoration Design Team drafts
> 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
>
>
>
>