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

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

Hi Lou,

Appreciate the careful review of the document.

Please see updated draft diffs attached and advise if OK to publish it.

Please see inline for replies <RG> ..


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.


<RG> Added.


>
>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.


<RG> Updated.

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


<RG> Updated.

> 
>
>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]."


<RG> Updated.

>
>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.

<RG> Fixed, I should have caught it.


>
>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.


<RG> Updated both.


>
>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.


<RG> Ok.


>
>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.


<RG> Ok.


>
>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,


<RG> It was there in the following paragraph. I edited the two paragraphs
for clarity.


>
>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


<RG> Both sections updated as follows:


6.1.  Association Types

   IANA maintains the "Generalized Multi-Protocol Label Switching
   (GMPLS) Signaling Parameters" registry (see
   http://www.iana.org/assignments/gmpls-sig-parameters).  "Association
   Type" subregistry is included in this registry.

   This registry will be updated by new Association Types for
   ASSOCIATION and Extended ASSOCIATION Objects defined in this document
   as follows:


   Value    Name                                            Reference
    0     Reserved                                           [RFC4872]
    1     Recovery (R)                                       [RFC4872]
    2     Resource Sharing (S)                      [RFC4873][RFC6780]
    TBD   Double Sided Associated Bidirectional LSP (D)    Section 4.2
    TBD   Single Sided Associated Bidirectional LSP (A)    Section 4.2


6.2.  REVERSE_LSP Object

   IANA maintains the "RSVP Parameters" registry (see
   http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml).
    Class Names, Class Numbers, and Class Types subregistry is included
   in this registry.

   This registry will be extended for new Class Number (Class-Num) and
   Class Type (C-type) for RSVP REVERSE_LSP Object requested in the
   11bbbbbb range defined in this document as follows:


     Class Number   Class Name              Reference
       199         ASSOCIATION               [RFC4872]
       TBD         REVERSE_LSP               Section 4.4


   - REVERSE_LSP Object: Class Type or C-type = 1

 





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


Thanks Lou,

Regards,
Rakesh



>
>Lou
>
>
>
>
>
>
>
>
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp