Document: Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions (draft-ietf-ccamp-inter-domain-rsvp-te-06.txt) Reviewer: Eric Gray Review Date: August 16, 2007 IETF LC End Date: August 16, 2007 IESG Telechat date: (if known) Unknown. Summary: ======= This document is not ready for publishing as a Proposed Standard. Some points require clarifications. Comments: ======== The following paragraph (section 2) seems inconsistent with the text in subsequent sections: it seems that it is saying that any combination of the three methods (contiguous, nested, stitched) could be used in a _single_ LSP - yet at least on of these is defined as "end-to-end" in subsequent text (contiguous). That would seem to imply that any combination except contigous and either of the other two. The paragraph reads: "In fact, as pointed out in [RFC4726], any combination of these three options may be used in the course of an end-to-end inter-domain LSP." Yet the subsequent text describing "Contiguous" says "a single end-to-end TE LSP ..." Possibly a careful read should be made to remove innappropriate uses of the words "end-to-end" in connection with each method? For example, in the cited case above, simply removing "single end-to-end" in the description of contiguous should remove the ambiguity in that case. Alternatively, assuming that it is actually the case that - for a contiguous LSP - the intent is that it be truly end-to-end, then the original statement above needs to be modified. Finally, if it is fact the intent that the selection method is supposed to apply to any given LSP - on an end-to-end basis - then the quoted statement above should be removed entirely. -------------------------------------------------------------------- Still related to the above, but as a side note, the fact that it is not immediately clear which of these is the intention in this document is an indication of a potential for some very serious interoperability issues. Some of the subsequent text mentions the potential for a "policy failure" that SHOULD fail the setup. In addition to not being absolutely clear (when would it be okay not to fail, is there a way to indicate that an alternative is allowed, etc?), this implies that it is possible for a domain to have a policy (for example, against contiguous LSP setup) that is going to result in complete non-interoperation with a domain (or implementation) asking for contiguous LSP setup. This sort of policy conflict may easily arise if one implementer, or operator, interprets the specification one way and another (or others) interprets it another in terms of expected "end to end" behavior and combinations of the types of "spanning" LSPs. --------------------------------------------------------------------- The last two paragraphs in section 2 (preceding the heading for section 2.1) are confusing and (potentially) contradictory: one appears to say that signaling extensions (for control/selection of methods) are in scope while specific details are not, but the other seems to say otherwise. I suspect that the word "control" is where I am getting hung-up. If it is intended that the specifics of each method are out of scope in this document - once a method is selected - then it is hard to see how "control [...] of the three signaling mechanisms" is in scope but "specific protocol extensions required to signal each LSP type" is not. Perhaps "control and" should be removed? ---------------------------------------------------------------------- In section 3, under bullet 4a - on page 6 - you use "SHOULD" in saying whether or not a PathErr message is to be generated. Why - or under what circumstances - would it be appropriate not to do so? ---------------------------------------------------------------------- Similarly, on page 7, you use the word SHOULD with respect to ERO processing in a Path message. When (or under what circumstances) would it make sense not to do as specified? What alternatives are there? This same observation then applies to several (all?) of the actual procedures - although several of them do provide some degree of amplification as to when (or why) a specific step might not apply. Perhaps it would be best to clarify in the steps themselves and - rather than say "SHOULD" in the introductory statement, it might be enough to simply say that the following procedures apply (thus avoiding the issue of using either SHOULD or MUST). ---------------------------------------------------------------------- After "However:" in section 3.2, I would suggest some form of modification or qualification of the first bullet similar to: - A domain border node MUST NOT passively suppress propagation of a PathErr message. Clearly, if the device applies a successful crankback approach, it does not make sense for it to propagate the PathErr anyway. ---------------------------------------------------------------------- In the third bullet of section 7, page 15, "do not need to be considered" does not follow from "are likely to be upgraded". True - if they are upgraded - then they are unlikely to need to be considered in backward compatibility discussion. But "likely to be" is NOT the same as "are". The point I think you are trying to make is that upgrading a border LSR to include this capability is an essential enabling requirement for useful operation of this capability - and that makes it unnecessary to consider such upgraded border LSRs in backward compatibility. ====================================================================== NITs: In section 1.2, page 3, the definition for ASBR should start with an expansion of the acronym. ---------------------------------------------------------------------- In section 3.1, as currently formatted, the "factors including:" seems to be "Farrel, Ayyangar and Vasseur" - an artifact of the way that your document only has a single empty text-line between the last line of content-text and the page footer. This is only a problem when reading the electronic version and - most likely - a (humorous) temporary problem that will fall out in subsequent versions. If not, it might be a good idea to force the line with a colon ending it to not orphan the next line of content-text. In the version I read, this occurs at the bottom of page 6. ----------------------------------------------------------------------- On page 14, second paragraph, I suggest changing "ingress LSP" to "LSP ingress". An LSP - however qualified - cannot "exert control". ----------------------------------------------------------------------- First line in section 7, existing rather than esiting. ----------------------------------------------------------------------- Last line of the first bullet in section 7 (page 15, roughly mid page) - inter-domain rather than inte-domain. ----------------------------------------------------------------------- Third line of third bullet (in section 7), controls verses conrols. ----------------------------------------------------------------------- Third line of second paragraph (in section 8, page 15), suitable instead of suiable.