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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Thank you Lou for the review.

We will go through the comments and address/reply accordingly.

Thanks,
Rakesh


On 2014-09-12 5:28 PM, "Lou Berger" <[e-mail]> wrote:

>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
>
>
>
>
>
>
>
>
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp