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

Gregory Mirsky <> Wed, 10 February 2016 19:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B0C61B2EDA; Wed, 10 Feb 2016 11:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mw4iNL76mvXc; Wed, 10 Feb 2016 11:06:58 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01B0F1B2ED9; Wed, 10 Feb 2016 11:06:56 -0800 (PST)
X-AuditID: c618062d-f79d16d000001b1c-e1-56bb86cf4b61
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 95.A7.06940.FC68BB65; Wed, 10 Feb 2016 19:51:59 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 10 Feb 2016 14:06:54 -0500
From: Gregory Mirsky <>
To: Lou Berger <>, "" <>, "" <>, TEAS WG <>, "CCAMP (" <>
Thread-Topic: comment on draft-ietf-mpls-residence-time
Thread-Index: AQHRXDT5bSUNiSX6T0W7JnL+kOquQJ8bfEvggACkDQCACZDN0A==
Date: Wed, 10 Feb 2016 19:06:53 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_002_7347100B5761DC41A166AC17F22DF112219C4A10eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0hTYRjG+c7Ozo6r0dda+WZ2cRlZaJqYrisWFEYXRGNSf1SjDirq1E1N I7srtmpmKuVRM8iVl8orYW5BmDYv4SyloptZFhtoiSIWXWw7X4LUf7/3ex/e93kfPlYkNzMe bKw2hdNpNfFKRkrnp1qi/GzZZnVAx6i7arDkJa161NMpUeWcGaZVr0yVYlXWtyY6VBxWXv6d ChupP8OEU/ukGw5z8bFpnM5/00FpTNuPWippdE966fNc8Uk0GW5AbizgIHhiG0WE50HPuxrG gKSsHLcieGhvRaS4heBGnVXiUjE4EOx1FySuhgL3I6hvu0m5GnNwMJwaMQujFDgE7KfNFOEt YOjrpF1M42XAZ98RGRDLyvAuuGpJJAuqENQZi4QFbng7jJUYBT1yWprovC3MEWF3eDVYRhGr Chh42sUQnguOj7/FhJVw2dQtJvpYuF9uFViGZ0NH0SB9CSn4aaP4aTJ+mox32hPhFVDT7E8k XlBwfkBC2BMaCs8h3mlbhLMQ3GsvFfPCDY0ICi62SEhRh6DC1P63U0JB78VxihT5zsiGqoXd DF4PdyusDC/EZKeg0OHJC1HuAEfZfYq8R0DWWBcivAr6X78QvLqiLLRkU8R3KHz+mif59zbA vjCUV/yXN0LuRDEijKHcYhMRXghDZdfE/LQoXUYB98+A/OJqiSsM1zf59X7+f7msB+ONXObf jKZivI4WVSE2VZ8UnxAdGFCPnN/4MTB+Taj/yvYWhFmknCkLCGlWy8WaNH1GQgvydo75UFvd gzxobaKWUypkSzLNarnssCbjKKdLPKBLjef0LWgBSyvdZabQGrUcR2tSuDiOS+J0U12KdfM4 iaSTft6eyQ1ezR0VJ44v7o3bPGvv0rft1jdbq/us42rVpa7Gc9qBBzMsUdsaubPHjIk71wU7 ct6q26syHR2RWp/lwZre/VfMWyq3rflkSw8K+XnogkdE92l3yaTUpzD5WUPazfAj3mGtiqi1 E8mBwfJmg90wbAsy+j5f1GDyjyz9sltJ62M0q1eKdHrNH0l9AGnOAwAA
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: Wed, 10 Feb 2016 19:07:00 -0000

Hi Lou,
thank you for your thoughtful comments and insightful suggestions. I've updated the draft to address them. Now we propose new RTM_SET sub-object. If RTM required RSSO placed in LSP_ATTRIBUTES object. I've looked into definition of LSP_REQUIRED_ATTRIBUTES object and believe that it is not well suited for RTM because in heterogeneous environment, where not all LSRs understand RSSO, such LSR will reject Path message. Please let us know whether changes address your comments.

Dear All,
appreciate your questions, comments,  suggestions.


-----Original Message-----
From: Lou Berger [] 
Sent: Thursday, February 04, 2016 3:52 AM
To: Gregory Mirsky;;; TEAS WG; CCAMP (
Subject: RE: comment on draft-ietf-mpls-residence-time


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)

--- Begin Message ---
A new version of I-D, draft-ietf-mpls-residence-time-02.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:		draft-ietf-mpls-residence-time
Revision:	02
Title:		Residence Time Measurement in MPLS network
Document date:	2016-02-10
Group:		mpls
Pages:		24

   This document specifies G-ACh based Residence Time Measurement and
   how it can be used by time synchronization protocols being
   transported over MPLS domain.

   Residence time is the variable part of propagation delay of timing
   and synchronization messages and knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a PTP event


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

--- End Message ---