[CCAMP] Comments on draft-ietf-ccamp-rsvp-te-srlg-collect-04

Lou Berger <lberger@labn.net> Wed, 07 May 2014 21:54 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 164D51A03B7 for <ccamp@ietfa.amsl.com>; Wed, 7 May 2014 14:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.267
X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rqOR8om5waLM for <ccamp@ietfa.amsl.com>; Wed, 7 May 2014 14:54:00 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com []) by ietfa.amsl.com (Postfix) with SMTP id B4F971A0257 for <ccamp@ietf.org>; Wed, 7 May 2014 14:54:00 -0700 (PDT)
Received: (qmail 28505 invoked by uid 0); 7 May 2014 21:53:50 -0000
Received: from unknown (HELO CMOut01) ( by gproxy4.mail.unifiedlayer.com with SMTP; 7 May 2014 21:53:50 -0000
Received: from box313.bluehost.com ([]) by CMOut01 with id z9tZ1n00S2SSUrH019tcnD; Wed, 07 May 2014 15:53:50 -0600
X-Authority-Analysis: v=2.1 cv=EOmVjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=0n_1n4a9CTgA:10 a=YsrfA5SUEYcA:10 a=HFCU6gKsb0MA:10 a=MGRxyiorQo4A:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=EIv9BKRZKx1pkf5HHdIA:9 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=0i0cJLWQ2Ty/ttHWeaSZ56wLJTmX/QrZMbgm4OEq/O0=; b=Q65Y6iwZpt3+KWE3Rc6xxIYCul4Ho/xCEZfN049KCZr5y4+QlnfKAX/84ed5pcYqPFipG7jMho8xi6NCjw0mSxEuULLmInd2r3zBaHpNdOEZG4jQKhvHv8qZF5xtAmDH;
Received: from box313.bluehost.com ([]:55867 helo=[]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1Wi9mP-00055I-9s; Wed, 07 May 2014 15:53:33 -0600
Message-ID: <536AAB57.2090403@labn.net>
Date: Wed, 07 May 2014 17:53:27 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" <draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/MvcgM2BVldmwwcherCY-5VkuVks
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] Comments on draft-ietf-ccamp-rsvp-te-srlg-collect-04
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: Wed, 07 May 2014 21:54:02 -0000

    Here are some primarily editorial suggested changes to / comments on
draft-ietf-ccamp-rsvp-te-srlg-collect-04.  Please use/respond as you
see appropriate.

- The draft has a bunch of idnits issues which need to be fixed
  (I'll use line numbers from this URL below.)

- I suggest, in the whole document

- Section 3 title: "RSVP-TE Extensions (Encoding)"
  The whole document is an RSVP-TE Extensions, so this isn't a very
  useful section heading.  How about just calling the "Encodings"

- Section 3.2
  - Each field should have its length defined
  - The reserved field needs to be defined

Section 4.1

-  lines 179-181:
   Typically, the head node gets the route information of an LSP by
    adding a RRO which contains the sender's IP addresses in the Path

  - Given this is defined in RFC209, how about:

   Per RFC 3209, an ingress initiates the recording of the route
    information of an LSP by adding a RRO to a Path message.

- There are places where the section is light on 2119 language:
  - line 181: s/it sets/it MUST set
  - line 182: s/which can be carried/which MAY be carried

- lines 183/4: Given you are describing specific cases, s/if/when in the

   either in an LSP_REQUIRED_ATTRIBUTES Object if the collection is
   mandatory, or in an LSP_ATTRIBUTES Object if the collection is

- drop "is" in "...  Collection Flag is set" (lines 188 and 196)

- you use "should not" in lower case in a few spots in this section.
  While I think your usage *is* correct, my experience is that someone
  (probably in the IESG) will tell you that these need to be in upper
  case at some point.  Of course, they'll be wrong, and this will have
  to be explained.  I suggest avoiding 2119 language in lower case where
  easily avoided.  How about s/should not be/is not to be

- Line 200: " the SRLG sub-object(s) in the Path RRO."
  How about "any SRLG sub-object(s) in the RRO of the corresponding
  outgoing Path message."

- Line 202: s/If/When the Collection Flag is set and

- Line 203/4:
       processing node SHOULD add an SRLG sub-object to the RRO to carry the
       local SRLG information.
       processing node SHOULD add local SRLG information, as defined
       below, to the RRO of the corresponding outgoing Path message.

- Line 208: s/forwarding/processing

- line 210:
      node can get the SRLG information from the RRO
       node receives SRLG information in the RRO

- Lines 212-215 - this needs to be rephrased into language with which an
  implementation may conform.  How about something like:

    Per RFC 3209, when issuing a Resv message for a Path message which
    contains an RRO an egress node initiates the RRO process by adding
    an RRO to the outgoing Resv message.  The processing for RROs
    contain in Resv messages then mirrors that of the Path messages.

- Line 224: s/must not/MUST NOT

- Lines 225-7
   Otherwise, if local policy allows to provide the SRLG
   information, it MUST add an SRLG sub-object to the RRO to carry the
   SRLG information in the upstream direction.
   When local policy allows recording SRLG
   information, the node SHOULD add SRLG information, as defined below,
   to the RRO of the corresponding outgoing Resv message.

- Lines 246-250.  I don't think such informative text belongs in this
  section.  I also think it's redundant with the last paragraph of
  section 1 so suggest dropping it altogether.

- The section is missing handling of RRO to big. Perhaps add it at ~line

Section 4.2
 - Line 260: s/need not/SHOULD NOT

Section 4.3 Compatibility (?)
- Need a section covering what happens when an existing implementation
  sees a flag or SO defined in this document.  (Remember, you can't
  specify their behavior, just say what they should be expected to do
  based on current RFCs and the objects defined in this document.)

- Section 5
  The section doesn't cover the possibility of SRLGs being
  mapped/changed from/to internal to/from neighbor SRLG values.

- Section 6
  Section 5 implies there is a policy decision to be made at border
  nodes. It seems to me that the security related considerations of this
  policy decision should be covered in the document. Either in this
  section or in section 5, in which case this section should point to
  that discussion.

- Section 9
  The references need to be split into informative and normative
  references.  For example, all but the first two references look
  informative to me.

That's it,