Draft: draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Reviewer: Gray, Eric [Eric.Gray@marconi.com] Review Date: Friday 9/8/2006 4:07 PM IETF LC Date: 9/8/2006 Summary: ------- This document is almost ready for publication as a Proposed Standard RFC. It is - over-all - clear, concise and easy to read. There are a few comments below that I feel should be addressed in some way before it is published. ============================================================ Comments: --------- In section 1.1, you say: "This document does not preclude a route exclusion from listing arbitrary nodes or network elements to avoid. The intent is, however, to indicate only the minimal number of subobjects to be avoided." This is an aspect of probably the most serious drawback to what this draft proposes. I can't easily come up with scenarios in which it is more difficult to specify the elements you want a route to include than it is to say which elements you want it to exclude. In fact, it is reasonably easy to see that the complexity of an "include description" is on the same order as the complexity of the desired end-product route. Not so, at all, for an "exclude description" whose complexity is not bound at all (effectively) since you _could_ describe a route explicitly as the one route that is left after you exclude all others (including routes that have loops in them). What does this document propose as a means to protect an implementation from another implementations proposing a literally arbitrarily complex exclusion list? IMO, a new error code - corresponding to "XRO too complex" would be one approach - if an XRO exceeds some measurement of complexity RECOMMENDED by the specification. (Of course, this introduces a management consideration, as it should then be possible to determine tolerance for complexity of at least the locally managed nodes.) ------------------------------------------------------------ In section 2, you include the following sentence: "This subobject might also be appropriate for use within Explicit Routes or Record Routes, but this is outside the scope of this document." I read this is "You could do 'X', but this document does not discuss 'X'." What's the point in including this sentence? ------------------------------------------------------------ In section 2.1, you describe the format of a new SRLG object - which is itself "word aligned" by inclusion of a two-octet "Reserved" field, but which does not "word align" the SRLG ID itself by simply putting the Reserved field in the first word. I realize this comment comes up frequently and that it is not usually a problem for modern implementations to deal with word-alignment problems, but wanted to know what the authors' thinking was in this case. Is the Reserved field purely for padding to a word boundary, or do the authors anticipate that it might eventually by used for something else? If it might be used for something else, do authors anticipate that something else might scope the SRLG, or be scoped by it? ------------------------------------------------------------ In two places, you refer to the SRLG object type as "TBD by IANA" - in section 2.1 (in the description of "Type" under the format figure) and again in section 3.1 (in the table of XRO subobjects). In section 3.1, you have two places in which you refer to "Exclude Route Class value" - once in the first paragraph (as [TBD]) and once just above the figure showing format of the object (as "Class = TBD by IANA"). This seems to set up some possibly complicated instructions to IANA (which are not - by the way - included in the IANA Considerations section), and the RFC Editor, in order to avoid the embarassing situation in which the draft gets published as a Proposed Standard with values that appear to be [TBD]. I recommend replacing these references with recognizable "variable names" - e.g. [SRLGO-IANA] and [XRClass-IANA] - which are then referenced in IANA considerations as well. Then the RFC Editor instructions could be as simple as "please replace all instances of [XXX-IANA] with the appropriate values assigned by IANA..." This same observation applies to "Explicit Exclusion Route Subobject" - but there you have a "variable name" (EXRS). ------------------------------------------------------------ In section 3.2, bullet 3, you state that ERO and XRO MUST NOT contradict each other - and then go into a relatively interesting and complicated description of how to resolve such a contradiction. You should make up your mind. Either the ERO and XRO "SHOULD NOT contradict each other" and here is what you do if they do, or they "MUST NOT contradict each other" and here is the error code you return. IMO, the request initiator SHOULD construct a request that is free of contradictions between XRO and ERO. In the event that expansion of one or the other later introduces a contradiction, the steps you describe would apply to resolving it. ------------------------------------------------------------ In section 3.2, very little is said about what it means to say "SHOULD be avoided" - other than the text in the 3rd bullet on resolving a contradiction and the short bit in the 4th bullet about minimizing the number of instances of selecting resources that were listed as "SHOULD avoid". IMO, this is insufficient. Since the XRO can be reduced, and it is not necessarily the case that any node could determine how many instances of "SHOULD be avoided" have already occurred, the quality of this control knob is a bit weak. For one thing, short of explicitly listing examples of when it might be appropriate to select an expansion that does not minimize "SHOULD avoid" resources - or at least explicitly stating the considerations involved - this document SHOULD say "MUST be minimized" ("minimised" is perfectly acceptable, since you're using that version of the English language). Also, it would be useful to include some text about the process of route selection in the case where multiple routes exist and the local node is not in the process of expanding an ERO. ------------------------------------------------------------ In the 2nd bullet of section 6, you state that support for EXRS is optional. IMO, you need to state how messages containing an EXRS are handled by an implementation that does not support EXRS, if support for EXRS is optional. If this is included in section 4.2 (which may or may not be a good idea - since that SHOULD be a description of how EXRS is supported, not "not supported"), it does not jump out at me. I recommend describing how this is done (or why it does not matter) in the body of this second bullet. ------------------------------------------------------------ I disagree with section 7. The current document introduces a potentially arbitrarily complex object without offering an "opt-out" mechanism. This at least slightly increases the exposure of resulting implementations to a DoS attack against the signaling control plane. ============================================================ Editorial/NITs: -------------- In section 3, first paragraph, "exlude" should be "exclude" (middle of the 3rd line of the paragraph). ------------------------------------------------------------ In section 3.1, first paragraph after the format figure, "subojbects" should be "subobjects" (beginning of the 3rd line of the paragraph). ------------------------------------------------------------ In the description of the "L" bit under all of the objects in section 3.1, you use the words "MUST be excluded" and "SHOULD be avoided" - is there a difference in meaning of "excluded" and "avoided"? Note that in the general text, toward the beginning of section 3.1, you say: "The concept of loose or strict hops has no meaning in route exclusion. The L bit, defined for ERO subobjects in [RFC3209], is reused here to indicate that an abstract node MUST be avoided (value 0) or SHOULD be avoided (value 1)." It's not a big deal (hence it is in the "NITs"), but it probably would raise less dust if the wording was more consistent. ------------------------------------------------------------ In section 3.2, bullet number 2, "SHOULDreturn" should be "SHOULD return" (middle of second line of the bullet text). ------------------------------------------------------------