Document: draft-ietf-mpls-bundle-06.txt Review: Lucy E. Lynch Date: 2 mars 2005 Link Bundling in MPLS Traffic Engineering draft-ietf-mpls-bundle-06.txt "This draft has serious issues, described in the review, and needs to be rethought" (or expanded) The current version of this document really reads as a GMPLS "insiders" guide. Most terms need to expaned on first use (TLVs, TE, etc.). Lots of references to outside material and not enough explanation or case examples in this document for it to stand on its own. The problems are mostly in the first half of the document (sections 5 and 6 are much easier to read). NOTES: A question - the abstract states: "This document updates the interface identification TLVs defined in GMPLS Signaling Functional Description, [RFC3471]." How is "updates" different from obsoletes? How will readers of RCF3471 know about the updates? 4. Link Bundling "In other cases, a combination of is not sufficient." Case examples would be nice here. The paragraph that follows could be miscontrued to be just such an example ("Consider a TE link such that") although it turns out to be a strawman example of how a bundle is constructed. The last sentence in this section it states: "To limit the amount of losses one need to restrict the type of the information that can be aggregated/abstracted." not sure what is meant by need... Is it "one need will be to" or "one needs to" 4.1 "All component links in a bundle must begin and end on the same pair of LSRs, have the same Link Type (i.e., point-to-point or multi-access), the same Traffic Engineering metric, and the same set of resource classes at each end of the links. A Forwarding Adjacency may be a component link; in fact, a bundle can consist of a mix of point-to-point links and FAs." Does this mean that FAs can be part of a point-to-point bundle but not a multi-access bundle? "If the component links are all multi-access links, the set of IS-IS or OSPF routers connected to each component link must be the same, and the Designated Router for each component link must be the same. If these conditions cannot be enforced, multi-access links must not be bundled." MUST NOT ? 4.2 "Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links. Procedures for doing this are outside the scope of this document. In the future, as new Traffic Engineering parameters are added to IS-IS and OSPF, they should be accompanied by descriptions as to how they can be bundled, and possible restrictions on bundling." Cross WG review/notice needed here? 4.3 "Typically, an LSP's ERO will identify the bundled link to be used for the LSP, but not the component link, since information about the bundled link is flooded, but information about the component links is not. The identification of a component link in an ERO is outside the scope of this document. When the bundled link is identified in an ERO or is dynamically identified, the choice of the component link for the LSP is a local matter between the two LSRs at each end of the bundled link." A second item punted as "outside the scope of this document" - is this being worked on elsewhere? How does this need to indentify component links relate to the need for bundles? "In the special case where the same label is to be valid across all component links, two TLVs SHOULD used in an IF_ID RSVP_HOP object or IF_ID TLV." should read "two TLVs SHOULD be used" ? "Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV." So, don't do this bad thing, but when you do it anyway, you have to do it this way? 4.3.1. Interface Identification TLV Format "This section modifies section 9.1.1. of [RFC3471]." is this the right way to do this? (see IANA changes below as well) 8. IANA Considerations This document changes the recommended usage of two of the Interface_ID Types defined in [RFC3471]. For this reason, the IANA registry of GMPLS Signaling Parameters should be updated for those types to read: 4 12 See below COMPONENT_IF_DOWNSTREAM - Deprecated [BUNDLE] 5 12 See below COMPONENT_IF_UPSTREAM - Deprecated [BUNDLE] NITS: idnits 1.60 tmp/draft-ietf-mpls-bundle-06.txt: Abstract section seems to be numbered Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3667/3668 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : * The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? (Expected a match on the following text: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress"." ... but found this: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress."") Miscellaneous warnings: None. Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774