[CCAMP] Comments / questions on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09

[Lou Berger <[e-mail]>]

Authors,
    As part of processing the early allocation request, I've the chairs
review of the draft.  I have some comments and questions.  I know I've
previously sent comments on the draft, nonetheless  I still found some
topics to discussion on this version.

General comment:
- I think the phrase "reverse unidirectional LSPs" should be formally
defined in the document.

Section 4.2: I propose some more consistent/flexible wording
OLD
      For double sided provisioning, Association Source MUST be set to
      an address selected by the node that originates the association
      for the bidirectional LSP (which may be a management entity.)

      For single sided provisioning, Association Source MUST be set to
      an address assigned to the node that originates the LSP.
NEW
      Association Source MUST be set to
      an address selected by the node that originates the association
      for the bidirectional LSP. For example, this may be a management
entity, or
     in the case of single sided provisioning, an address assigned to
the node that
     originates the LSP.

Section 4.4.1
- You need to assign and name C-Type 1 (it's not TBD). 

Section 4.4.2
- You should explicitly state the format of the subobects, perhaps
something along the lines of: "Subobjects have the same format as RSVP
Objects, see Section 3.1.2 of [RFC2205]."

Section 5.1 (I might have proposed this text, so the error is mine!)
OLD
   types SHOULD NOT be used in ASSOCIATION objects carried in Path
   messages and SHOULD be ignored if present.
NEW
   types SHOULD NOT be used in ASSOCIATION objects carried in Resv
   messages and SHOULD be ignored if present.

3rd to last paragraph need to point to section 5.3
OLD
    Note that teardown procedures of the
NEW
    Generally, the teardown procedures of the
and
OLD
    state removal).
NEW
    state removal). See Section 5.3below for additional rules related to 
    LSPs established using single sided provisioning.

Section 5.1.1
TEXT says:
   As specified in [RFC4872], an endpoint node that does not support the
   new Association Types defined in this document MUST return a PathErr
   message with the error code "LSP Admission Failure" (value 01 as
   defined in [RFC2205]) and the sub-code "Bad Association Type" (value
   5 as defined in [RFC4872]).

Humm, In keeping with being liberal in what you accept, I always
interpreted the admittedly vague reference (2nd to last paragraph of
section 16 in RFC4872)  to  define the error for a failure in
"appropriate PROTECTION object  settings" rather than an unknown
association type. I think the above should be dropped.

Section 5.2.1 2nd paragraph
    This is a unique interpretation of 2205's definition for handling
unknown c-types in the form of 11bbbbbb.  I suggest dropping the paragraph.

Section 5.3

The section is missing the handling of teardown when the REVERSE_LSP is
present.  Perhaps just drop:
 
   For the single sided provisioning where the REVERSE_LSP Object is not
   signaled,

Section 6.1
- Drop the suggested values
- please copy the table format from the text version of the registry and
then show the exact changes you'd like to see made (with the caveat of
using TBD where the assignments go) . See RFC5226 for general directions.
- The final paragraph should be the 1st, and the other section text
adjusted accordingly.

Section 6.2
- Drop the first "(TBD)"
- Fix the text to distinguish between class number and c-type and which
is being requested and defined.
- also same final 2 comments from 6.1

I think that's it.  I'd like to get these issues resolved before putting
in the early allocation request.

Lou