RE: [Gen-art] Gen-ART LC review ofdraft-ietf-ccamp-inter-domain-rsvp-te-06.txt

["Eric Gray" <[e-mail]>]

I have reviewed the changes incorporated in the -07 version and
I believe that all of the issues I raised during the last call
have been addrssed.  

At this time, I believe the current draft is ready to publish
as a Proposed Standard RFC.

Thanks, to the authors, for their prompt response in addressing
these last call comments!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]] 
> Sent: Thursday, August 16, 2007 12:56 PM
> To: Adrian Farrel; JP Vasseur; Arthi Ayyangar
> Cc: Ross Callon; [e-mail]
> Subject: [Gen-art] Gen-ART LC review 
> ofdraft-ietf-ccamp-inter-domain-rsvp-te-06.txt
> 
> Authors,
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> 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.
> 
> 
> 
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art