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

From: Lou Berger <[email-masked]>
Date: Fri, 12 Sep 2014 17:28:05 -0400

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 12 Sep 2014 22:26:35 +0000

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" <[email-masked]> wrote:

>_______________________________________________
>CCAMP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 13 Sep 2014 13:22:15 +0000

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

>- I think the phrase "reverse unidirectional LSPs" should be formally

<RG> Added.

>     in the case of single sided provisioning, an address assigned to

<RG> Updated.

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

<RG> Updated.

>Objects, see Section 3.1.2 of [RFC2205]."

<RG> Updated.

>   messages and SHOULD be ignored if present.

<RG> Fixed, I should have caught it.

>    LSPs established using single sided provisioning.

<RG> Updated both.

>association type. I think the above should be dropped.

<RG> Ok.

>unknown c-types in the form of 11bbbbbb.  I suggest dropping the

<RG> Ok.

>   For the single sided provisioning where the REVERSE_LSP Object is not

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

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

>in the early allocation request.

Thanks Lou,

Regards,
Rakesh

---

From: Lou Berger <[email-masked]>
Date: Sat, 13 Sep 2014 11:40:24 -0400

Rakesh,

Looks fine, although I think section 5.3 could benefit from some additional 
tweaks.  That can be done as part of normal wg process. Also, you don't 
need to include current assignments in the iana section.

Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 13 Sep 2014 15:46:14 +0000

Thank you Lou.

I will address these comments and upload a new revision.

Thanks,
Rakesh