Re: [CCAMP] poll on making draft-margaria-ccamp-lsp-attribute-ero-02 a WG document

"Adrian Farrel" <> Mon, 10 December 2012 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9395821F86C2 for <>; Mon, 10 Dec 2012 15:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eHYFDC5Dqtfv for <>; Mon, 10 Dec 2012 15:20:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B8E2521F86B6 for <>; Mon, 10 Dec 2012 15:20:11 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id qBANKAbG002757; Mon, 10 Dec 2012 23:20:10 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id qBANK9Qj002750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Dec 2012 23:20:09 GMT
From: Adrian Farrel <>
To: 'Lou Berger' <>,
Date: Mon, 10 Dec 2012 23:20:08 -0000
Message-ID: <061a01cdd72c$e5b35340$b119f9c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac3XLDdBVIhdc2ZlTNmBYmSYzmALmA==
Content-Language: en-gb
Subject: Re: [CCAMP] poll on making draft-margaria-ccamp-lsp-attribute-ero-02 a WG document
X-Mailman-Version: 2.1.12
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: Mon, 10 Dec 2012 23:20:12 -0000

<very definitely speaking as an individual and not to be taken in any way as AD

When we defined the LSP attribute object, we deliberately did not include this
function. Our thinking was that we were defining attributes of the LSP and that
this function is defining behavior of specific nodes. Attributes of an LSP can
be classed as behavior of *all* nodes on the LSP, or behavior of the end points
of the LSP.

The two example use cases supplied by Mach in his email
( and are
helpful for understanding the intention of the work, but seem to support my
understanding of the purpose.

If the authors have a different intention (i.e., not targeting instructions at a
specific node on the LSP) then it would be helpful if they spoke up.

Otherwise (and assuming that this function is actually needed!) I think it would
be helpful to reclass this as a normal subobject of a normal ERO. This would
allow the ERO to pass through nodes that do not support the new subobject
without having to define a new top-level object that will not be understood and
without complicating the ERO processing further. Obviously, returning the fact
that the new subobject was processed will require a new RRO subobject.

I do not much care whether this change is made before or after adoption as a WG
draft, but I do believe it should be discussed at some point, and my current
view is that the change should be made at some point.

I think adoption probably hinges on whether the WG believes that there is a need
to target commands at specific nodes on the LSP.


> -----Original Message-----
> From: [] On Behalf Of
> Lou Berger
> Sent: 07 December 2012 20:48
> To:
> Subject: [CCAMP] poll on making draft-margaria-ccamp-lsp-attribute-ero-02 a
> WG document
> All,
> This is to start a two week poll on making
> draft-margaria-ccamp-lsp-attribute-ero-02 a ccamp working
> group document. Please send mail to the list indicating "yes/support"
> or "no/do not support".  If indicating no, please state your technical
> reservations with the document.
> The poll ends Friday December 21.
> Much thanks,
> Lou (and Deborah)
> PS We're still waiting on one IPR statement.
> _______________________________________________
> CCAMP mailing list