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

Lou Berger <lberger@labn.net> Fri, 12 September 2014 21:28 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6731A00EF for <ccamp@ietfa.amsl.com>; Fri, 12 Sep 2014 14:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DbiVbFUkVqf for <ccamp@ietfa.amsl.com>; Fri, 12 Sep 2014 14:28:19 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id E38821A0049 for <ccamp@ietf.org>; Fri, 12 Sep 2014 14:28:18 -0700 (PDT)
Received: (qmail 15041 invoked by uid 0); 12 Sep 2014 21:28:17 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 12 Sep 2014 21:28:17 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id qMU11o00p2SSUrH01MU4Ja; Fri, 12 Sep 2014 15:28:16 -0600
X-Authority-Analysis: v=2.1 cv=LbyvtFvi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=E-FxpA8jQUoA:10 a=74g-w6MbfcgA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=5ndCV5RuwWvTgZ6FbfsA:9 a=FW9_BIlXMoH99MPm:21 a=RXnrPuFw2XzF9pLY:21 a=wPNLvfGTeEIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=w8Dfa3b0edumwbtAEmWOR5kZgaupY4e38mtfB9IYyWE=; b=o1+cAHVeAP7m80ksEgZqu/77ZCnAidFs9/whAuIhfUa2HdipuNaxENc4HCZupySX5CdQi93MmynyUapwrdbTmH8pFaRjFSvcgAPpA+sOkG4V+OpVkjHKEmCGdN2y6hLJ;
Received: from box313.bluehost.com ([69.89.31.113]:43965 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1XSYNu-00027u-D6; Fri, 12 Sep 2014 15:28:02 -0600
Message-ID: <54136565.6090104@labn.net>
Date: Fri, 12 Sep 2014 17:28:05 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/jT14mEvd-YHHuGpQGJh74OHOcAY
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] Comments / questions on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 21:28:20 -0000

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