Re: [CCAMP] comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Fri, 09 May 2014 20:28 UTC

Return-Path: <rgandhi@cisco.com>
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 BAB591A00E3 for <ccamp@ietfa.amsl.com>; Fri, 9 May 2014 13:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level:
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 luoPd0HheXsh for <ccamp@ietfa.amsl.com>; Fri, 9 May 2014 13:28:21 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA11A00D5 for <ccamp@ietf.org>; Fri, 9 May 2014 13:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12909; q=dns/txt; s=iport; t=1399667296; x=1400876896; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/WzPdo5mL3vPul4Ekg7a99f8QtgivBcjvjXj4sz58l0=; b=kwfivpJk+LVIqUiCeUEgeHvfyYyYF1MdbKIAebYZr0hBewm+oE80obAP xm33Cx0wvCytImGuyM5QOzuk7ExVqvxp5Itaw798akY1Frp/HKuCKda1l Ks0JPPdX+PypC/P/AsYWYmcGdpHJ9D9UYIx5bAK+82ZxRICx4CaWk9aJf s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMFAOI5bVOtJA2K/2dsb2JhbABPCoMGT1i+GIc8AYEaFnSCJwEEAQEBJBMtBwsSAQgOKDcLJQIEDgUZiCgN0RkXjXYpCCsHhEAElU+DeIE8kUaDNoFvJBw
X-IronPort-AV: E=Sophos;i="4.97,1020,1389744000"; d="scan'208";a="42566714"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 09 May 2014 20:28:14 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s49KSEuf008043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 20:28:14 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.162]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 9 May 2014 15:28:14 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Lou Berger <lberger@labn.net>, "draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org" <draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org>
Thread-Topic: [CCAMP] comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08
Thread-Index: AQHPa8UzrV5Nu6AqB0qKAOs67vHbbw==
Date: Fri, 9 May 2014 20:27:26 +0000
Message-ID: <CF92B231.295A9%rgandhi@cisco.com>
In-Reply-To: <536D103A.1060304@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [161.44.213.2]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0D1358D151E43F449C306C732855F427@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/toFGzLysn-sJ79tYfvLaDquYm9I
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08
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, 09 May 2014 20:28:23 -0000

Thank you Lou for the detailed review of the draft.

We will go through these comments and update/advise accordingly.

Thanks again,
Rakesh and co-authors



On 2014-05-09 1:28 PM, "Lou Berger" <lberger@labn.net> wrote:

>Hi,
>
>Here are some editorial and technical suggested changes to / comments on
>draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-08.  Please
>use/respond as you see
>appropriate. 
>
>- The draft has a bunch of idnits issues which need to be fixed
>  see
>hhttp://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccam
>p-mpls-tp-rsvpte-ext-associated-lsp-08.txt
>  (I'll use line numbers from this URL below.)
>
>- Line 18-20:
>  OLD
>   achieved by defining the new Association Types in (Extended)
>   ASSOCIATION object.  In addition, RSVP extensions allow asymmetric
>   upstream and downstream bandwidths for the bidirectional LSP.
>  NEW
>   achieved by defining new Association Types for use in ASSOCIATION and
>   in Extended ASSOCIATION objects. One of these types enables
>   independent provisioning of the associated bidirectional LSPs, while
>   the other enables single sided provisioning. The REVERSE_LSP Object
>   is also defined to enable a single endpoint to specify all the
>   parameters of an associated LSP in the single sided provisioning case.
>
>- Line 147
>  s/an/the
>  s/object/objects
>
>- Line 148:
>  Add new sentence: "This document refers to the [RFC4872] defined
>  ASSOCIATION objects and the [RFC6780] defined the Extended ASSOCIATION
>  objects collectively as the (Extended) ASSOCIATION objects."
>
>- Lines 150-154
>  OLD
>   This document specifies mechanisms for binding two reverse
>   unidirectional LSPs into an associated bidirectional LSP. The
>   association is achieved by defining new Association Types in the
>   (Extended) ASSOCIATION object. RSVP extensions allow asymmetric
>   upstream and downstream bandwidths for the bidirectional LSP.
>  NEW
>   This document specifies mechanisms for binding two reverse
>   unidirectional LSPs into an associated bidirectional LSP. The
>   association is achieved by defining new Association Types for use in
>   (Extended) ASSOCIATION objects. One of these types enables
>   independent provisioning of the associated bidirectional LSPs, while
>   the other enables single sided provisioning. The REVERSE_LSP Object
>   is also defined to enable a single endpoint to specify all the
>   parameters of an associated LSP in the single sided provisioning
>   case. For example, the REVERSE_LSP Object allow asymmetric upstream
>   and downstream bandwidths for the associated bidirectional LSP.
>
>
>- You introduce the terms "single sided and double sided provisioning" in
>  this document.  This is fine, but they shouldn't have a recursive
>  definition.  I therefore suggest
>  - Line 180: s/side/endpoint
>  - Lines 118,190: s/sides/endpoints
>
>- Line 183: drop "to this"
>
>- Line 264:
> OLD
>   New REVERSE_LSP object applicable to the single sided provisioning
> New
>   A new REVERSE_LSP object for use in the single sided provisioning
>
>- Line 266-268
> OLD
>   the existing SENDER_TSPEC object is
>   added in the REVERSE_LSP object as a subobject in the initiating
>   LSP's Path message to specify the reverse LSP's traffic parameters.
> NEW
>   a SENDER_TSPEC object can be
>   added in the REVERSE_LSP object as a subobject in the initiating
>   LSP's Path message to specify an different bandwidth for the reverse
>   LSP. 
>
>- Line 270
>  Add at end of sentence: "by including other existing objects in a
>  REVERSE_LSP object."
>
>- line 275
>  s/inserts SENDER_TSPEC subobject/inserts a SENDER_TSPEC subobject for
>                                   use by LSP2
>
>- Line 283/4
>  s/asymmetric bandwidths independently/separate bandwidths, which may
>                                       or may not be identical.
>
>- Section 3.4
>  - Perhaps it's worth starting out the section with an informative
>    description of how recovery is impacted before jumping into an
>    illustrative example.
>
>- Section 3.4.1,  Lines 305-6
>  Has anyone actually implemented what this says???  I don't think it
>  says what you intend.  My understanding was that the recovery of each
>  LSP would be independent and based on the parameters signaled in their
>  respective path messages (same as 3.4.2), and both must use the
>  identical (Extended) ASSOCIATION objects as used in during initial LSP
>  establishment.  The only difference (between single and double) is
>  that the egress of the initiating LSP would need to recognize that the
>  recovery LSP is tied to the existing reverse LSP. (Which really
>  should fall out of normal processing anyway.)
>
>  (No matter what the processing rules need to be aligned with the
>  resulting text.)
>
>- Section 3.5
>   As I read it, this section says  mesh-group LSPs using
>   associated bidirectional use this (associated bidirectional)
>   document. is that your intent?  If so, I think the section adds no
>   value and should be dropped.
>
>  Alternatively, is it your intent to say that mesh-group LSPs MUST NOT
>  use corouted bidirectional signaling?  If so, this should be explicitly
>  stated, discussed and agreed to by the WG.
>
>- Ordering of sections 4 & 5
>  So section 4, which is called processing rules, starts with section
>  4.1/4.2 which essentially defines formats.  I think the document would
>  more readable if it started with the format definitions and then went
>  on to procedures.  Yes this is certainly an editorial/style comment,
>  but I found the current formulation quite confusing.  Also 5.2 is
>  completely redundant with 4.1.
>
>- Lines 352/4 shouldn't these be LSP not LSPs?
>
>Section 4.3 - Lines 394-427 - Suggested reordering, edits and additions:
>
>(lines 394-39)
>   This document defines the processing for the association of two
>   unidirectional LSPs to form an associated bidirectional LSP.
>   Such association is based on the use of an (Extended) ASSOCIATION
>   object.
>(lines 420-427)
>   The procedures related to the actual identification of associations
>   between LSPs based on (Extended) ASSOCIATION objects are defined in
>   [RFC6780]. [RFC6780] specifies that in the absence of Association
>   Type-specific rule for identifying association, the included
>   (Extended) ASSOCIATION objects in the LSPs MUST be identical in order
>   for an association to exist. This document adds no specific rules
>   for the new Association Types defined, and the identification of LSP
>   association therefore proceeds as specified in [RFC6780].
>(lines 411-418)
>   As described in [RFC6780], association of LSPs can be upstream or
>   downstream initiated, as indicated by (Extended) ASSOCIATION objects
>   in Path or Resv Messages.  The association of bidirectional LSPs is
>   always upstream initialized, therefore the Association Types defined
>   in this document are only to be interpreted in Path Messages.  These
>   types SHOULD NOT be used in ASSOCIATION objects carried in Path
>   messages and SHOULD be ignored if present. Only one
>(lines 398-402)
>   To indicate an associated bidirectional LSP, an ingress MUST insert
>   an (Extended) ASSOCIATION object into the Path message of the
>   unidirectional LSP that is part of the associated bidirectional LSP it
>   initiates. If either Global Association Source or Extended
>   Association Address is required, then an Extended ASSOCIATION object
>   [RFC6780] MUST be inserted in the Path message. Otherwise, an
>   ASSOCIATION object MAY used. Only one (Extended) ASSOCIATION object
>   with the Association Types defined in this document SHOULD be
>   included by an egress in an outgoing Path message. (Extended)
>   ASSOCIATION objects with both single sided and double sided
>   Association Types MUST NOT be added in the same Path message.
>(lines 404-409)
>   The ingress node MUST set the Association Type field in the
>   (Extended) ASSOCIATION object to "Single Sided Associated
>   Bidirectional LSPs" when single sided provisioning is used, and to
>   "Double Sided Associated Bidirectional LSPs" when double sided
>   provisioning is used.
>(new)
>   A transit node MAY identify the unidirectional LSPs of an associated
>   bidirectional LSP based on (Extended) ASSOCIATION objects, with the
>   Association Type values  defined in this document, carried in Path
>   messages. Clearly, such associations are only possible when the LSPs
>   the transit node. As defined above, such associations are made per
>   the rules defined in [RFC6780].
>
>   Egress nodes which support the Association Types defined in this
>   document identify the unidirectional LSPs of an associated
>   bidirectional LSP based on (Extended) ASSOCIATION objects carried in
>   Path messages.  Note that an ingress node will normally be the ingress
>   for one of the unidirectional LSPs that make up an associated
>   bidirectional LSP.  When an egress node receives a Path message
>   containing an (Extended) ASSOCIATION objects with one of the
>   Association Types defined in this document, it MUST attempt to
>   identify other LSPs (including ones for which it is an ingress node)
>   with which the LSP being processed is associated.  As defined above,
>   such associations are made per the rules defined in [RFC6780].
>
>- Section 4.3.1 Covers tear down, but what about setup and changes to
>  single sided provisioned reverse LSPs?  This really needs to be
>  specified.
>
>  How about moving & modifying 459/460 to the end of the previous
>  section:
>
>    No additional processing is needed for Path messages with an
>    (Extended) ASSOCIATION object containing an Association Type field
>    of Double Sided Associated Bidirectional LSP.
>
>  and then rename
>
>   Section 4.3.1. Single Sided Associated Bidirectional LSP Processing
>
>  and have it cover the setup, modification, and teardown cases. It
>  should include how the reverse LSP's objects are created from the
>  triggering LSP, both when the REVERSE_LSP object is present and when
>  it isn't.  It should also cover/mention the possibility of when
>  modification to (or even a new) the originating LSP does or doesn't
>  change a previously established reverse LSP.
>
>  Lines 505-509 also belong in this section as they relate to
>  single sided provisioning in general and not just REVERSE_LSP object
>  processing.
>
>    -- Let me know if you get stuck and I'll try to help.
>
>- Lines 429-440: move to the end of section 4.3.2
>
>- Line 432: s/MAY exist/can be present
>
>- Line 433: s/MAY/can
>
>- Line 452 (new paragraph):
>   When an LSP signaled with a Path message containing an (Extended)
>   ASSOCIATION object with an Association Type defined in this document
>   is torn down, the processing node SHALL remove the binding of the LSP
>   to any previously identified associated bidirectional LSP.
>
>- Line 478: s/MAY/MUST
>  (how else could it control the reverse LSP)
>
>- Line 480:  s/LSP/LSP originating
>- Line 480/1: Drop "and to specify the reverse LSP's traffic parameters."
>
>- Line 485/486: "A REVERSE_LSP object MUST contain at least one
>subobject."
>
>  What does it include if their are no objects to include?
>
>- Line 489: s/endpoint/egress
>
>- Line 492->501: reorder and revise:
>
>   An egress node, upon receiving a Path message containing one or more
>   REVERSE_LSP objects MUST verify that the Path message contains an
>   ASSOCIATION or Extended ASSOCIATION object with the Association Type
>   set to "Single Sided Associated Bidirectional LSPs". If it does not,
>   the message MUST NOT trigger a reverse LSP.  This verification
>   failure SHOULD NOT trigger any RSVP message but can be logged
>   locally, and perhaps reported through network management mechanisms.
>
>   Once validated, the egress MUST use the subobjects contained in any
>   present REVERSE_LSP objects in the management of the reverse LSP
>   described in the previous section.  Note that the contents of a
>   REVERSE_LSP object may change over the life of an LSP and such
>   changes MUST result in corresponding changes in the reverse LSP.
>
>- Section 4.4.1  - belongs in 4.3.1.
>
>- Line 544
>  s/[ <REVERSE_LSP]/[ <REVERSE_LSP> ... ]
>
>- Line 579 s/subobjects/objects
>
>- Section 6, this section should identify the registries impacted in
>  this document.  See draft-ietf-ccamp-gmpls-signaling-g709v3-12 for a
>  recent example.
>
>- Section 9.2
>  I'd say 3473 is normative.
>
>_______________________________________________
>CCAMP mailing list
>CCAMP@ietf.org
>https://www.ietf.org/mailman/listinfo/ccamp