Re: [mpls] comment on draft-ietf-mpls-residence-time

Lou Berger <> Thu, 04 February 2016 11:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B1211AD0C2 for <>; Thu, 4 Feb 2016 03:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Status: No, score=-2.367 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p8i2QoOxF-GU for <>; Thu, 4 Feb 2016 03:52:18 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id EC3231AD370 for <>; Thu, 4 Feb 2016 03:52:17 -0800 (PST)
Received: (qmail 27341 invoked by uid 0); 4 Feb 2016 11:52:14 -0000
Received: from unknown (HELO cmgw2) ( by with SMTP; 4 Feb 2016 11:52:14 -0000
Received: from ([]) by cmgw2 with id EBs81s0062SSUrH01BsBNY; Thu, 04 Feb 2016 04:52:12 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=jFJIQSaiL_oA:10 a=0FD05c-RAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=N4ziCMIgapIhUI46dQIA:9 a=HjWpKTxPLtYyWCyS:21 a=RttmczWeqyfvkZoT:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=z9nPrvl8cjKunsMbrH/2TxPJXp/jtBZJXnM3HeZYXQo=; b=s0GFG48gbK8qs1xwf5SherNtXw7Oz8d1lR9lzJWyd7x0PK4IsVyZTUJnmGKWMB8tFc8n1yvD/3h7XMOA5AlHlnF0lKR2qfnoAaRMqHcYy7JrnRLrxptOA5VlQQy2LbYd;
Received: from [] (port=57620 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from <>) id 1aRISH-0000tf-Lz; Thu, 04 Feb 2016 04:52:09 -0700
From: Lou Berger <>
To: Gregory Mirsky <>,,, TEAS WG <>, "CCAMP (" <>
Date: Thu, 04 Feb 2016 06:52:06 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/ (build: 24000016)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Identified-User: {} {sentby:smtp auth authed with}
Archived-At: <>
Subject: Re: [mpls] comment on draft-ietf-mpls-residence-time
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2016 11:52:20 -0000


Thank you for looking at this. See below.

On February 4, 2016 2:11:12 AM Gregory Mirsky <> 

> Hi Lou,
> I've followed on your suggestion to investigate use of already available 
> objects. I’ve looked into LSP_ATTRIBUTES Object [RFC5420]. Per my analysis 
> we can consider two options:
> •         introduce RSO sub-objects with RTM_Capability sub-TLVs ordered as 
> defined in the current RTM draft, to be used in LSP_ATTRIBUTES Object;

Given 5420 is silent on TLV ordering, I think you need a single RTM 
Attributes TLV, which contains your sub objects carried as sub-tlvs.

I think the new TLV could be allowed in both LSP_ATTRIBUTES and 
LSP_REQUIRED_ATTRIBUTES objects to cover when RTM is optional/required e2e. 
Just LSP_ATTRIBUTES would be equivalent to what you currently define.

> •         use RRO Attributes sub-object that will be present in RRO Object 
> and define new RTM Capability Flag(s) from IANA Attribute Flags registry. 
> Rules defined in Section 7.3 RFC 5420 would apply.
> Number of Attribute flags is variable, thus the latter option is as 
> flexible as the former or current option documented in our draft.

I ruled out the second option in my earlier email as I generally consider 
RROs  a weak approach to supporting LSP control (since they are subject to 
all sorts of generally policy related processing and are 'at risk' in large 

That said, the introduction of address to this object does required a note 
in the document on the policy implications, e.g., that processing at  
boundaries such as envisioned in rfc4208 may require rro-like policy 
processing. But this doesn't change my feeling that piggybacking control on 
RRO is generally a 'bad idea'.


> Greatly appreciate your consideration, comments, suggestions.
> 	Regards,
> 		Greg
> -----Original Message-----
> From: Lou Berger []
> Sent: Sunday, January 31, 2016 10:38 PM
> To:;
> Subject: comment on draft-ietf-mpls-residence-time
> Hi,
> 	I see you propose defining a new RSVP object class that has application 
> specific scope.  As I'm sure you know the RSVP class-number space is really 
> small so it's best to avoid allocating new object classes whenever 
> possible.  I believe there is an existing object class that you can use for 
> your purposes -- the LSP_ATTRIBUTES object.
> Have you considered carrying RTM Hops in 1 (or three,  depending on if you 
> want sub-tlvs or not) new RTM Attribute TLV (or TLVs)?
> If not, I think it is worth exploring the viability of this approach or any 
> other approach that doesn't require the allocation of a new class-num.
> Lou
> (As contributor and TEAS co-chair)