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

"Rakesh Gandhi (rgandhi)" <> Fri, 12 September 2014 22:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 63DBB1A0077 for <>; Fri, 12 Sep 2014 15:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hOpZrKV2s7Yj for <>; Fri, 12 Sep 2014 15:26:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26A5A1A00BF for <>; Fri, 12 Sep 2014 15:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4190; q=dns/txt; s=iport; t=1410560797; x=1411770397; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2Unl3cDq1I/gTvj3Tm5qU3jMTPeuVEX/QczorN2EAQo=; b=CsgIQ9Qxu8QZk2EAB5Ss56jlMRpCgi4vTi5E5UeZPqE2kFtqs07SFSnv ec9H0h9r/fknmgk6bdhhvGcVlHGU/gt3HETQQAIi7ZtwgCS5G7FHnmHJX axPz8EpokRjGoS3KXLkiikFYfPpNW2FLeBOVeCAlBaxGqYk/N6DfZR2Fn s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,515,1406592000"; d="scan'208";a="77498133"
Received: from ([]) by with ESMTP; 12 Sep 2014 22:26:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s8CMQajr012522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 22:26:36 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 17:26:35 -0500
From: "Rakesh Gandhi (rgandhi)" <>
To: Lou Berger <>, "" <>
Thread-Topic: [CCAMP] Comments / questions on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09
Thread-Index: AQHPztB//oATcdaRA0GpozCdhbtFCJv+JFaA
Date: Fri, 12 Sep 2014 22:26:35 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP <>
Subject: Re: [CCAMP] Comments / questions on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-09
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Sep 2014 22:26:40 -0000

Thank you Lou for the review.

We will go through the comments and address/reply accordingly.


On 2014-09-12 5:28 PM, "Lou Berger" <> wrote:

>    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
>      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.
>      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!)
>   types SHOULD NOT be used in ASSOCIATION objects carried in Path
>   messages and SHOULD be ignored if present.
>   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
>    Note that teardown procedures of the
>    Generally, the teardown procedures of the
>    state removal).
>    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
>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.
>CCAMP mailing list