Re: [mpls] [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt

Gregory Mirsky <gregory.mirsky@ericsson.com> Fri, 08 April 2016 02:27 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277F612D122; Thu, 7 Apr 2016 19:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 C7TbevQWPhaH; Thu, 7 Apr 2016 19:27:55 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC11312D50E; Thu, 7 Apr 2016 19:27:54 -0700 (PDT)
X-AuditID: c6180641-f79fa6d0000057a9-db-570717035afe
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id FC.A0.22441.30717075; Fri, 8 Apr 2016 04:27:15 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 22:27:53 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Lou Berger <lberger@labn.net>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Thread-Topic: [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt
Thread-Index: AQHRfv7AabajoYyQ8ESTiHRUKGeJAJ9a/5YwgABc5ID//77vIIABKK6A///XwlCAAEa4AIAADf4QgA3+coD///fdoAAJpv8AAAA/DDAACChiAAKQw23g
Date: Fri, 8 Apr 2016 02:27:51 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A3FD70@eusaamb103.ericsson.se>
References: <20160315210754.7666.49708.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A0D437@eusaamb103.ericsson.se> <56E88F6B.8010506@labn.net> <7347100B5761DC41A166AC17F22DF11221A0D5AC@eusaamb103.ericsson.se> <56E951B5.2050803@labn.net> <7347100B5761DC41A166AC17F22DF11221A0DE4E@eusaamb103.ericsson.se> <56E96B46.1060706@labn.net> <7347100B5761DC41A166AC17F22DF11221A0E248@eusaamb103.ericsson.se> <56F5342F.2080002@labn.net> <7347100B5761DC41A166AC17F22DF11221A24A46@eusaamb103.ericsson.se> <56F56E22.80801@labn.net> <7347100B5761DC41A166AC17F22DF11221A24CDF@eusaamb103.ericsson.se> <56F5A688.2080807@labn.net>
In-Reply-To: <56F5A688.2080807@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/mixed; boundary="_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Se0hTURzHObuPXc3BaZv5y+w1DaX3u1EWSS9DjCDKiqJGXdSauja1LAp7 aD56aPZwty0XmWnpLBV7irRS00Cz1x8Ls7Rg+cDQSqOS7t1ZIP33Oef3/b2+53CU8jPrz8XG J/LGeJ1ew3rTeUmPomZQfvKo2f0uP23G8V5aO2y1UFr7qyZW67xewmjThu7Ry5nwwsKfsvCv FcfZcOFSOrue2uodupvXxybzxlnLdnrHdB+10Ib2XHTgW6NZnorK92chLw7wfHhYm0MRHgMv 3pezWcibU+I6BDVleXJyKELQmX2RlVQsnguuO6fkEqtxHDjLXjMSUzgU6hrqaIlVeBt0dB31 aLZDs8uKpEJqfAxBq9PuLkTjIHhS2+hurcCRkFP8zp2sxFkM9J5cKrEXDoHv1S4kMRLHG2wq lZFmfuD8VCAjY6vhY+tzlrAvfOkcZghrwNL9liL6WMio6JKTXqOh0fyJzkG+wohSwgiZMEJG 7qeD7WE/S3gaFF3tpggHQOWFTCSIu1E4DUF6czUjuB2rRNDV3uDOUOLbCL7+UpCAVQb1Dwo9 qjwEOWfSZUQlHlqbVwpuj5eAvZhkq/E8MP8YEJkTewRCU1uAhCocBq2ZJqJYDfkl5RThmfCn 6RkS3K8QBFb7ACN4zM50ZtNkszCw2c662QcvhF9dvRRhA7w8cZclbALzhzrqf4dAdKIn97KH l0LG4/cMYQyFj1oowuOhp+CK5548iLQuYJsCnG86PIH50Jb2QG5DM24iLslk0MdFz51TgcQP Xw9s2D1Uc3qtA2EOaXwUNiyPUjK6ZFNKnAMFifN03L71AvnT8QnxvEatkKvEsGK3LuUgb0zY YUzS8yYHGsfRGj9FxJbhTUocrUvk9/K8gTf+i8o4L/9UZHh8uIx+tbhv4pTBU+tG9fUsKm1w 3bqYd+x14p6gYOeogDWdqRsyA8xZVQWTA48cKimvab5hz/i8sUBVVZrilZ8ADZG7FqzunnSm qKVvc8Sy3/UTyhIdb47o29MH9UPhB8NWjGs/+/QahHBWy9jz5+6vGhpjuaDf16nMzq393SIz BYdqaFOMbs5UymjS/QVHde0s+AMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Ap0StSHZAVo4PG2LLqWbHkLM9uw>
Cc: "mpls@ietf.org" <mpls@ietf.org>, TEAS WG <teas@ietf.org>
Subject: Re: [mpls] [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2016 02:27:58 -0000

Dear All,
we've uploaded the new version of the draft. Per discussion with Lou have added a flag to RTM_SET TLV. The flag indicates failure by a node to calculate distance to the next downstream RTM node. Thus the ingress node may inspect the RTM_SET TLVs whether any has the flag set.

Appreciate your review, comments.

	Regards,
		Greg

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Friday, March 25, 2016 1:59 PM
To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
Cc: mpls@ietf.org; TEAS WG
Subject: Re: [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt

Great, thank you.  Feel free to unicast me a diff if you'd like.

Lou

On 3/25/2016 4:51 PM, Gregory Mirsky wrote:
> Hi Lou,
> I'll work on the update and will post after the meeting.
>
> 	Regards,
> 		Greg
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, March 25, 2016 9:58 AM
> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
> Cc: mpls@ietf.org; TEAS WG
> Subject: Re: [Teas] FW: New Version Notification for 
> draft-ietf-mpls-residence-time-05.txt
>
> Greg,
>
> On 3/25/2016 12:52 PM, Gregory Mirsky wrote:
>> Hi Lou,
>> Greatly appreciate you've found time during these extremely busy days before the IETF meeting.
>>
>> I agree, that there could be different ways a node can handle the RRO limitation. I addition to those you've suggested node may change RTM Capability state advertised in IGP-TE. I think that the choice can be left to a developer.
> I think the RSVP change should be in the draft as it impacts interoperability and expected behavior.
>
> Once this change is made I think the draft will be ready to progress.
>
> Lou
>
>> I've published the -06 version with all updates noted in my mail before the cut-off and if you agree with the changes perhaps Loa can start the WGLC at the most suitable time.
>>
>> 	Regards,
>> 		Greg
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Friday, March 25, 2016 5:51 AM
>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
>> Cc: mpls@ietf.org; TEAS WG
>> Subject: Re: [Teas] FW: New Version Notification for 
>> draft-ietf-mpls-residence-time-05.txt
>>
>> Greg,
>>     Sorry for not responding before the ID cutoff. 
>>
>> I think this is fine, but why not go a step further and have the 
>> nodes that have the limitation indicate that RTM can't be used, e.g., 
>> clear the RTM_SET  Attribute Flag and/or remove the RTM_SET TLV to 
>> notify the ingress of the issue.  This would allow the automatic 
>> detection of the
>> (corner) cases were there are actual issues and let RTM operate properly in the common case.
>>
>> Lou
>>
>> On 3/16/2016 3:11 PM, Gregory Mirsky wrote:
>>> Hi Lou,
>>> following the discussion we propose the following new paragraph before Section 4.7.1:
>>>    There are scenarios when some information is removed from an RRO due
>>>    to policy processing (e.g., as may happen between providers) or RRO
>>>    is limited due to size constraints .  Such changes affect the core
>>>    assumption of the method to control processing of RTM packets.  RTM
>>>    SHOULD NOT be used if it is not guaranteed that RRO contains complete
>>>    information.
>>>
>>> Hope that would address your concern with potential blackholed RTM packets.
>>>
>>> 	Regards,
>>> 		Greg
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Wednesday, March 16, 2016 7:19 AM
>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
>>> Cc: mpls@ietf.org; TEAS WG
>>> Subject: Re: [Teas] FW: New Version Notification for 
>>> draft-ietf-mpls-residence-time-05.txt
>>>
>>> Greg,
>>>     What happens when some information is removed from an RRO due to policy processing (e.g., as may happen between providers).  Couldn't the TTL calculation some up too small if the wrong SOs are removed, and wouldn't this result in a black hole of actual RTM messages?  How do you cover this case?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 3/16/2016 10:15 AM, Gregory Mirsky wrote:
>>>> Hi Lou,
>>>> thank you for the detailed explanation of the case. I agree that there could be other ways to handle it from what been described in the document. If a node ID of the first node in the RTM_SET TLV is not found in the RRO list, then the TTL will be set to 255 and packet will not be processed by intermediate RTM-capable nodes but arrive at LSP egress LSR. Thus not all RTM capable nodes will be accounted for in the Scratch Pad but still some nodes may. I'll add some text to highlight this case.
>>>>
>>>> 	Regards,
>>>> 		Greg
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Wednesday, March 16, 2016 5:30 AM
>>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
>>>> Cc: mpls@ietf.org; TEAS WG
>>>> Subject: Re: [Teas] FW: New Version Notification for 
>>>> draft-ietf-mpls-residence-time-05.txt
>>>>
>>>> Greg,
>>>>
>>>> Thanks for the response.  See below.
>>>>
>>>> On March 15, 2016 6:56:34 PM Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
>>>>
>>>>> Hi Lou,
>>>>>
>>>>> thank you for the most detailed comments. Please find my notes 
>>>>> in-line tagged GIM>>.
>>>>>
>>>>>  
>>>>>
>>>>>                 Regards,
>>>>>
>>>>>                                 Greg
>>>>>
>>>>>  
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>> Sent: Tuesday, March 15, 2016 3:41 PM
>>>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org
>>>>> Cc: mpls@ietf.org; TEAS WG
>>>>> Subject: Re: [Teas] FW: New Version Notification for 
>>>>> draft-ietf-mpls-residence-time-05.txt
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>> Greg,
>>>>>
>>>>>  
>>>>>
>>>>> On 3/15/2016 5:13 PM, Gregory Mirsky wrote:
>>>>>
>>>>>> Hi,
>>>>>> this version primarily addresses comments related to the proposed
>>>>> extensions to RSVP-TE and operation of the control plane in 
>>>>> support of Residence Time Measurement. Would appreciate the confirmation from Lou.
>>>>>
>>>>>  
>>>>>
>>>>> I don't think I saw a response to:
>>>>>
>>>>>> I think this doesn't always work, e.g., when RRO is modified due 
>>>>>> to policy or limited due to size constraints.  This has to be addressed.
>>>>>> I can see how to easily detect this situation, but not how to get 
>>>>>> the number of non-supporting hops.  I guess it's always possible 
>>>>>> to play ttl comparison games, but that's pretty ugly too.  Any 
>>>>>> thoughts?
>>>>> GIM>> The following text in Section 4.7 intended to handle the
>>>>> situation you've described:
>>>>>
>>>>>    If the node cannot find matching ID in RRO,
>>>>>
>>>>>    then it MUST try to use ID of the next node in the RTM_SET 
>>>>> until it
>>>>>
>>>>>    finds the match or reaches the end of RTM_SET TLV.  If match 
>>>>> have
>>>>>
>>>>>    been found, then the calculated value is used by the node as 
>>>>> TTL
>>>>>
>>>>>    value in outgoing label to reach the next RTM capable node on 
>>>>> the
>>>>>
>>>>>    LSP.  Otherwise, the TTL value MUST be set to 255.
>>>>>
>>>>> In essence, the node tries to locate the closest to it downstream 
>>>>> RTM-capable node. Otherwise, it sets TTL to 255 so that the RTM 
>>>>> packets arrive at egress LER.
>>>>>
>>>> So this doesn't cover the case where there are holes in the RRO -- which I think then translates to RTM black holes.  Also not covered is what happens during Resv processing if there is no room (or a policy) against adding local information.
>>>>
>>>> Perhaps it would just be better to add a section that explicitly states that the defined mechanism only works  in cases where full RRO is supported (i.e., where RRO is not limited due to size constraints or otherwise impacted due to policy)? -- not saying I like this, I just think it fills the open gaps in the spec - but at the price of limiting applicability.  I haven't spent too much time thinking about this so there may be a better solution out there.
>>>>
>>>> Lou
>>>>
>>>>>  
>>>>>
>>>>> Parts of Sections 4.6 and 4.7 are a bit rough and could stand a 
>>>>> reread and editorial pass.
>>>>>
>>>>> GIM>> I'm trying.
>>>>>
>>>>>  
>>>>>
>>>>> Section 4.7 says PathErr messages are sent in response to Resv 
>>>>> processing error.  This is clearly wrong.
>>>>>
>>>>> GIM>> Great catch! I'm ready to update to ResvErr in -06.
>>>>>
>>>>>  
>>>>>
>>>>> Lou
>>>>>
>>>>>  
>>>>>
>>>>>> Authors always welcome comments and questions about RTM.
>>>>>>             Regards,
>>>>>>                             Greg
>>>>>> -----Original Message-----
>>>>>> From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>>> [mailto:internet-drafts@ietf.org]
>>>>>
>>>>>> Sent: Tuesday, March 15, 2016 2:08 PM
>>>>>> To: Alexander Vainshtein; Gregory Mirsky; Stefano Ruffini; John 
>>>>>> Drake; Sasha Vainshtein; Eric Gray; Stewart Bryant; Eric Gray
>>>>>> Subject: New Version Notification for 
>>>>>> draft-ietf-mpls-residence-time-05.txt
>>>>>> A new version of I-D, draft-ietf-mpls-residence-time-05.txt
>>>>>> has been successfully submitted by Greg Mirsky and posted to the
>>>>> IETF repository.
>>>>>
>>>>>> Name:                               draft-ietf-mpls-residence-time
>>>>>> Revision:          05
>>>>>> Title:                  Residence Time Measurement in MPLS network
>>>>>> Document date:           2016-03-15
>>>>>> Group:                              mpls
>>>>>> Pages:                               26
>>>>>> URL:           
>>>>> https://www.ietf.org/internet-drafts/draft-ietf-mpls-residence-tim
>>>>> e
>>>>> -
>>>>> 05
>>>>> .txt
>>>>>
>>>>>> Status:        
>>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
>>>>>
>>>>>> Htmlized:      
>>>>> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05
>>>>>
>>>>>> Diff:          
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-0
>>>>> 5
>>>>>
>>>>>> Abstract:
>>>>>>    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
>>>>>>    message.
>>>>>>                                                                                  
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission until the htmlized version and diff are available at 
>>>>> tools.ietf.org.
>>>>>
>>>>>> The IETF Secretariat
>>>>>> _______________________________________________
>>>>>> Teas mailing list
>>>>>> Teas@ietf.org <mailto:Teas@ietf.org> 
>>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>> _______________________________________________
>>>>> Teas mailing list
>>>>> Teas@ietf.org <mailto:Teas%40ietf.org> 
>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>


--- Begin Message ---
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Residence Time Measurement in MPLS network
        Authors         : Greg Mirsky
                          Stefano Ruffini
                          Eric Gray
                          John Drake
                          Stewart Bryant
                          Alexander Vainshtein
	Filename        : draft-ietf-mpls-residence-time-07.txt
	Pages           : 27
	Date            : 2016-04-07

Abstract:
   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
   message.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-residence-time-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--- End Message ---