Re: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

[dimitri papadimitriou <[e-mail]>]

hi adrian

Adrian Farrel wrote:

> 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. 

thank for commenting here this will help in progressing the document

> However, there are a few more
> substantial questions hidden in the middle of what I have written.

will provide on the list how these comments have been addressed when 
document will be re-submitted (assuming that the last call is over now)

> 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.
> 
> 
> .
>