[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
Hi,
Here are my comments on this I-D. Most of these comments are very minor
editorial nits. We need to try to get these resolved at this stage because
it will improve the speed at which the IESG can review the I-D and reduce
the time in the RFC Editor process. However, there are a few more
substantial questions hidden in the middle of what I have written.
I suspect that this email will take some while to show up at the CCAMP
mailing list because psg (which hosts the CCAMP list) is in dispute with
my ISP. Sorry about that.
Thanks,
Adrian
====
Section 4
The following functionality is expected from GMPLS routing protocol
s/protocol/protocols/
Section 4
- Processing of routing information exchanged between adjacent
levels of the hierarchy (i.e. Level N+1 and N) including
reachability and upon policy decision summarized topology
information.
s/and upon policy decision summarized/and (upon policy decision)
summarized
Section 4
- Self-consistent information at the receiving level resulting from
any transformation (filter, summarize, etc.) and forwarding of
information from one Routing Controller (RC) to RC(s) at different
levels when multiple RCs bound to a single RA.
s/bound/are bound/
Section 4
As ASON does not restrict the control plane architecture choice used,
either a co-located architecture or a physically separated
architecture may be used. A collection of links and nodes such as a
s/architecture choice used/architecture choice/
s/co-locate/collocate/
Section 5
This section evaluates support of existing IETF routing protocols
with respect to the requirements summarized from [ASON-RR] in Section
4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The
latter in not addressed in the current version of this document.
There will be no future versions of this document (we hope).
What should you then say about BGP?
Probably that BGP is not considered a candidate protocol because...
Section 5.1
- Li is a logical control plane entity that is associated to a
single data plane (abstract) node. The Li is identified by the
TE Router_ID. The latter is a control plane identifier defined as
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
. RFC 3784: Traffic Engineering Router ID TLV (Type 134)
s/data plane (abstract) node/physical node/
1. Use same terminology as defined in previous bullet
2. Why say "abstract" for something that is physical?
Section 5.1
This contains multiple references to RFCs. Can you please insert square
bracket citations.
Section 5.1
- Li is a logical control plane entity that is associated to a
single data plane (abstract) node. The Li is identified by the
TE Router_ID. The latter is a control plane identifier defined as
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
. RFC 3784: Traffic Engineering Router ID TLV (Type 134)
Note: this document does not define what the TE Router ID is. This
document simply states the use of the TE Router ID to identify
the Li. Other documents (the referenced RFC 3630 and RFC
3784) provide the definitions.
There appear to be two contradictory paragraphs here. The first says
"...defined as...". The second says "...does not define..." Need to tweak
the words.
Section 5.1
Thus, the routing protocol MUST be able to advertise multiple TE
Router IDs.
You need to comment on whether this requires a modification to the
protocols as currently specified or not. This is, after all, the purpose
of this document.
Section 5.1
[ASON-REQ], does not enter into the identification of the logical
s/ASON-REQ/ASON-RR/
Section 5.2
Under these conditions, GMPLS link state routing protocols provide
the capability for RA Identification.
Add "without further modification"
Section 5.3
We focus on routing information exchange between Ri entities
(through routing adjacencies) within single hierarchical level.
s/within single/within a single/
Section 5.3
Routing information mapping between levels may require specific
guidelines.
...and these are out of scope?
Section 5.3
The control plane does not transport Pi information as these are
data plane addresses for which the Li/Pi mapping is kept (link)
local - see for instance the transport LMP document [LMP-T] where
s/information/identifiers/
Section 5.3 (three times)
Are "666B.F999.AF10.222C" and "1.1.1.1" intended to be representative of
specific address forms. If the latter is an IPv4 address, you should pick
one from the range allowed for example IP addresses.
Section 5.3
You should conclude with a statement that "OSPF and IS-IS therefore carry
sufficient node identification information without further modification."
Section 5.3
3) when using OSPF or ISIS as the IGP in support of traffic
engineering, RFC 3477 RECOMMENDS that the Li value (referred to the
"LSR Router ID") to be set to the TE Router ID value.
Please add citation for [RFC3477].
Section 5.3.1
From the list of link attributes and characteristics (detailed in
[ASON-RR], the Local Adaptation support information is missing as TE
link attribute. GMPLS routing does not currently consider the use of
dedicated TE link attribute(s) to describe the cross/inter-layer
relationships. All other TE link attributes and characteristics are
currently covered (see Table 1.)
I think this could be written more clearly. Try...
[ASON-RR] provides a list of link attributes and characteristics
that need to be advertised by a routing protocol. All TE link
attributes and characteristics are currently handled by OSPF and
IS-IS (see Table 1) with the exception of Local Adaptation support.
GMPLS routing does not currently consider the use of dedicated TE
link attribute(s) to describe the cross/inter-layer relationships.
Section 5.3.1
However, the representation of bandwidth requires further analysis
i.e. GMPLS Routing defines an Interface Switching Capability
Descriptor (ISCD) that delivers information about the (maximum/
minimum) bandwidth per priority an LSP can make use of.
s/an LSP can make use of/of which an LSP can make use/
Section 5.3.1
The latter
also may require definition of additional signal types (from those
defined in [RFC 3496]) to represent contiguous concatenation i.e.
STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
s/also may/may also/
s/RFC 3496/RFC3946/ !!!
Note that 3946 is a signaling I-D. It does not mention routing
advertisement. You may need to add some detail here to explain how this
RFC is relevant.
Section 5.3.1
perspective. However, it introduces some lost of information. This
lost of information affects the number of signals that can be used
but not the range they cover. On the other hand, if additional
technology specific information (such as capabilities) are
s/lost/loss/ (twice)
s/capabilities) are/capabilities) is/
Section 5.3.1
sub-TLV [GMPLS-OSPF]
GMPLS-OSPF is not in the references.
Section 5.3.1
Local SNPP link ID Link local part of the TE link identifier
sub-TLV [GMPLS-ISIS]
GMPLS-ISIS is not in the references.
Section 5.3.1
Note: Link Attributes represent layer resource capabilities and
their utilization.
Undoubtedly true, but missing a little context?
Section 5.3.2
Nodes attributes include the "Logical Node ID" (as detailed in
Section 5.1) and the reachability information as described in
Section 5.3.3.
The use of "include" implies there are other node attributes not discussed
here.
Either discuss them (if they exist) or fix the text by s/include/are/
Section 5.3.3
defined per address family, e.g., IPv4 and IPv6). However, [OSPF-
NODE] restricts to advertisement of Host addresses and not prefixes,
and therefore requires enhancement (see below).
s/restricts to advertisement/is restricted to advertisement/
Section 5.3.3
A similar mechanism does not exist for IS-IS as the Extended IP
Reachability TLV [RFC3784] focuses on IP reachable end-points
(terminating points), as its name indicates.
I assume you mean that "An extension similar to [OSPF-NODE] is not
required for IS-IS because the function is already included in the
Reachability TLV. However, both the Reachability TLV and [OSPF-TLV] do not
support the advertisement of reachability prefixes."
Section 5.4.
hence no specific capabilities are added to the routing protocol
s/are/need to be/
Section 5.5
level hierarchy, and disallow the advertising of routing information
s/disallow/disallows/
Section 5.5
downward in the hierarchy. [RFC2966] defines the up/down bit to
[RFC2966] is not in the references.
Section 5.5
[RFC1195] allows only advertising routing information upward in the
RFC 1195 is not in the references.
Section 5.5
downward in the hierarchy. [RFC2966] defines the up/down bit to
RFC 2966 is not in the references.
Section 5.5
OSPFv2 prevents that inter-area routes, which are learned from area
0 are not passed back to area 0. However, GMPLS makes use of Type 10
Rewrite as...
OSPFv2 prevents inter-area routes (which are learned from area 0)
from being passed back to area 0. However, GMPLS makes use of Type 10
Section 5.5
(area-local scope) LSA to propagate TE information [RFC3630], [GMPLS-
s/LSA/LSAs/
Section 5.5
which Type 10 Opaque LSA may carry the information that particular
s/LSA/LSAs/
s/particular/a particular piece of/
Section 5.5
back into an higher level RC.
s/an/a/
Section 5.6
Link state protocols have been designed to detect topological
changes (such as interface failures, link attributes modification).
Convergence period is short and involves a minimum of routing
information exchange.
Do link state protocols detect the changes or propagate them?
s/Convergence/The convergence/
s/and involves/and convergence involves/
Section 5.7
behalf multiple Li's creates the following issue as there is no more
a 1:1 relationship between the Router_ID and the TE Router_ID but a
/more/longer/
Section 5.7
and link remote (unnumbered) ID association may be not unique per
s/be not/not be/
Section 5.7
retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links
The RFC Ed. prefers that square brackets [] are used only for citations.
Can you use {}?
Section 6
respectively case 1), 2), 3) and 4). Additional base scenarios
(being not combinations or decomposition of entities) may further
complete this set in a future revision of this document.
Remove this sentence.
Section 6
In the below Figure 1:
s/In the below Figure 1:/In Figure 1 below:
Section 6
Please add captions to the figures. At the moment it is not completely
clear that cases 1, 2 and 3 appear in Figure 1, while case 4 appears in
Figure 3, and Figure 2 is a special representation of case 1.
New Section 7
Please add a new section after Section 6
"Summary of Necessary Additions to OSPF and IS-IS"
It is too hard for the reader to extract these from the I-D with complete
certainty.
Section 8.1
Is [LMP-T] really normative?
Is [OSPF-NODE] really normative? The draft will progress better if it is
not.
[RFC3667] and [RFC3668] don't need to be listed.
[RFC3946] is not referenced.
Section 8.2
[ASON-RR] is surely normative.