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
Content-Type: multipart/mixed;
 boundary="_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_"
MIME-Version: 1.0
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
Precedence: list

--_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear All,
we've uploaded the new version of the draft. Per discussion with Lou have a=
dded a flag to RTM_SET TLV. The flag indicates failure by a node to calcula=
te distance to the next downstream RTM node. Thus the ingress node may insp=
ect 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]=20
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-reside=
nce-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=20
> 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 be=
fore the IETF meeting.
>>
>> I agree, that there could be different ways a node can handle the RRO li=
mitation. I addition to those you've suggested node may change RTM Capabili=
ty state advertised in IGP-TE. I think that the choice can be left to a dev=
eloper.
> I think the RSVP change should be in the draft as it impacts interoperabi=
lity 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 WGL=
C 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=20
>> draft-ietf-mpls-residence-time-05.txt
>>
>> Greg,
>>     Sorry for not responding before the ID cutoff.=20
>>
>> I think this is fine, but why not go a step further and have the=20
>> nodes that have the limitation indicate that RTM can't be used, e.g.,=20
>> clear the RTM_SET  Attribute Flag and/or remove the RTM_SET TLV to=20
>> notify the ingress of the issue.  This would allow the automatic=20
>> 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 complet=
e
>>>    information.
>>>
>>> Hope that would address your concern with potential blackholed RTM pack=
ets.
>>>
>>> 	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=20
>>> draft-ietf-mpls-residence-time-05.txt
>>>
>>> Greg,
>>>     What happens when some information is removed from an RRO due to po=
licy 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 th=
is result in a black hole of actual RTM messages?  How do you cover this ca=
se?
>>>
>>> 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 i=
ntermediate RTM-capable nodes but arrive at LSP egress LSR. Thus not all RT=
M capable nodes will be accounted for in the Scratch Pad but still some nod=
es 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=20
>>>> 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.c=
om> wrote:
>>>>
>>>>> Hi Lou,
>>>>>
>>>>> thank you for the most detailed comments. Please find my notes=20
>>>>> in-line tagged GIM>>.
>>>>>
>>>>> =20
>>>>>
>>>>>                 Regards,
>>>>>
>>>>>                                 Greg
>>>>>
>>>>> =20
>>>>>
>>>>> -----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=20
>>>>> draft-ietf-mpls-residence-time-05.txt
>>>>>
>>>>> =20
>>>>>
>>>>> =20
>>>>>
>>>>> Greg,
>>>>>
>>>>> =20
>>>>>
>>>>> 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=20
>>>>> support of Residence Time Measurement. Would appreciate the confirmat=
ion from Lou.
>>>>>
>>>>> =20
>>>>>
>>>>> I don't think I saw a response to:
>>>>>
>>>>>> I think this doesn't always work, e.g., when RRO is modified due=20
>>>>>> to policy or limited due to size constraints.  This has to be addres=
sed.
>>>>>> I can see how to easily detect this situation, but not how to get=20
>>>>>> the number of non-supporting hops.  I guess it's always possible=20
>>>>>> to play ttl comparison games, but that's pretty ugly too.  Any=20
>>>>>> 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=20
>>>>> until it
>>>>>
>>>>>    finds the match or reaches the end of RTM_SET TLV.  If match=20
>>>>> have
>>>>>
>>>>>    been found, then the calculated value is used by the node as=20
>>>>> TTL
>>>>>
>>>>>    value in outgoing label to reach the next RTM capable node on=20
>>>>> the
>>>>>
>>>>>    LSP.  Otherwise, the TTL value MUST be set to 255.
>>>>>
>>>>> In essence, the node tries to locate the closest to it downstream=20
>>>>> RTM-capable node. Otherwise, it sets TTL to 255 so that the RTM=20
>>>>> packets arrive at egress LER.
>>>>>
>>>> So this doesn't cover the case where there are holes in the RRO -- whi=
ch I think then translates to RTM black holes.  Also not covered is what ha=
ppens during Resv processing if there is no room (or a policy) against addi=
ng local information.
>>>>
>>>> Perhaps it would just be better to add a section that explicitly state=
s that the defined mechanism only works  in cases where full RRO is support=
ed (i.e., where RRO is not limited due to size constraints or otherwise imp=
acted 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 have=
n't spent too much time thinking about this so there may be a better soluti=
on out there.
>>>>
>>>> Lou
>>>>
>>>>> =20
>>>>>
>>>>> Parts of Sections 4.6 and 4.7 are a bit rough and could stand a=20
>>>>> reread and editorial pass.
>>>>>
>>>>> GIM>> I'm trying.
>>>>>
>>>>> =20
>>>>>
>>>>> Section 4.7 says PathErr messages are sent in response to Resv=20
>>>>> processing error.  This is clearly wrong.
>>>>>
>>>>> GIM>> Great catch! I'm ready to update to ResvErr in -06.
>>>>>
>>>>> =20
>>>>>
>>>>> Lou
>>>>>
>>>>> =20
>>>>>
>>>>>> 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=20
>>>>>> Drake; Sasha Vainshtein; Eric Gray; Stewart Bryant; Eric Gray
>>>>>> Subject: New Version Notification for=20
>>>>>> 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:          =20
>>>>> https://www.ietf.org/internet-drafts/draft-ietf-mpls-residence-tim
>>>>> e
>>>>> -
>>>>> 05
>>>>> .txt
>>>>>
>>>>>> Status:       =20
>>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
>>>>>
>>>>>> Htmlized:     =20
>>>>> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05
>>>>>
>>>>>> Diff:         =20
>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-0
>>>>> 5
>>>>>
>>>>>> Abstract:
>>>>>>    This document specifies G-ACh based Residence Time Measurement=20
>>>>>> 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=20
>>>>>> timing
>>>>>>    and synchronization messages and knowing what this delay is=20
>>>>>> for each
>>>>>>    message allows for a more accurate determination of the delay=20
>>>>>> to be
>>>>>>    taken into account in applying the value included in a PTP event
>>>>>>    message.
>>>>>>                                                                     =
            =20
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission until the htmlized version and diff are available at=20
>>>>> tools.ietf.org.
>>>>>
>>>>>> The IETF Secretariat
>>>>>> _______________________________________________
>>>>>> Teas mailing list
>>>>>> Teas@ietf.org <mailto:Teas@ietf.org>=20
>>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>> =20
>>>>>
>>>>> =20
>>>>>
>>>>> _______________________________________________
>>>>> Teas mailing list
>>>>> Teas@ietf.org <mailto:Teas%40ietf.org>=20
>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>



--_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_
Content-Type: message/rfc822
Content-Disposition: attachment; creation-date="Fri, 08 Apr 2016 02:27:47 GMT";
 modification-date="Fri, 08 Apr 2016 02:27:47 GMT"

Received: from ESESSHC006.ericsson.se (153.88.183.36) by
 EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id
 14.3.248.2; Thu, 7 Apr 2016 22:23:45 -0400
Received: from sessmg12.ericsson.net (153.88.183.153) by
 smtp.internal.ericsson.com (153.88.183.37) with Microsoft SMTP Server id
 14.3.248.2; Fri, 8 Apr 2016 04:23:43 +0200
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])	(using TLS with
 cipher DHE-RSA-AES256-SHA (256/256 bits))	(Client did not present a
 certificate)	by sessmg12.ericsson.net (Symantec Mail Security) with SMTP id
 B6.1D.04165.E2617075; Fri,  8 Apr 2016 04:23:43 +0200 (CEST)
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id 8F5F812D68A;	Thu,  7 Apr 2016 19:23:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
 (Postfix) with ESMTP id A0FC612D1DA; Thu,  7 Apr 2016 19:23:15 -0700 (PDT)
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt
Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt
Thread-Index: AQHRkT2tr5n08rKQj0SHKG3eK7PZFA==
Sender: mpls <mpls-bounces@ietf.org>
Date: Fri, 8 Apr 2016 02:23:15 +0000
Message-ID: <20160408022315.10081.77696.idtracker@ietfa.amsl.com>
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>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>,
 <mailto:mpls-request@ietf.org?subject=unsubscribe>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: ESESSHC006.ericsson.se
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-brightmail-tracker: H4sIAAAAAAAAA11Uf0wTdxTn27u2x4+Doy3wqIDSZRAciiCyZtkImpmQZQnLsoxlf8wVOGlj
 KaxXHGyLAWHqgI0qkRQirDhk8ycGkJ8lmx0lE0SBDWHK5ogoDoYRcfywQ3bXK7T4T/O593nv
 83nv3esRmGTVW07QeQZar1NpFSIvHN/cG70tJlCcuqOvRqy8XtGMKRfuLouVU5MlSGk9XY8p
 S7p6Rco7tePiJFHys39HRO+gD71ez6C1moO0PibxYy/1mbnDeE6Zb5710py4ALV6lSBPAqh4
 uNBTJ+RxIAz+2SgqQV6EhKoRQMvQKM4/nETw6Eg74h5w6iIGtsWfnSUhcLzeJuYwToXDrYFS
 4XpFwb0TjiSS8odrVZM4h0VUGJyfrmSVCEJGbYL++368jgwejUxgPAYwW4wCDiM2fan3ngNT
 FAXPTwzivORuMJvLcd73ZWg4MoH4/PfgSkG7Ix9jbR/8sIhzVlI2f+grhpeXw2xdh4DHwWB8
 3ObAPtRr0HpsQchjBqr+smE8ToTbtUvOnHB4OHjHmZMA9ulZZ04ODBe3iXjbaDB3PXHizdA2
 e8qRI6S2QHP5lANLqQj4Zuq+0Ii2VLstqNqtvNqt3IywcyiAoRkmKzM2bjut16QzTLZuu442
 NCH2Nq622OPa0ejCbiuiCKTwIc2UOFUiVB1k8rOsKJMQKOTkiFSUKpGmZWfkq1WMeh+Tm5al
 YRhNtk4RQL7ty6b7rnP6XC3NKGSkUsaGyfVwWq72ACtk4qIuIR39KaOlDeyhWhEQGFsmlnJl
 Gar8z2h9Ni9mRZsIXBFERpxnm6AyVQb6AE3n0Po19jj7iihzmXEUUWUFZeOIqrxwrhvJcV22
 juZ/FaEk8vDwkATq6Uw6b79Gyxq6DwHkM64vf3eanyOIvEawDOXOOEYJJT0otp0Niu7TCAhP
 K0onfBTBvLWEyVFlMZpMd1sZmRLATbtG8ZZS8ibXjM9a1GEXTPZwwXUVl1UfKkRE06+L40jC
 TxxC/s51FsClqnN1G0eVB5FHOSHKjXXYygPJPTvZMj83gnNm5fakYRvlXOZr35ZhFCqX8oP6
 sG8mS2NwDuPkp9FRAXtbQBYJuT1rdIYXViElJx1DOxm+WEKOc0FvZ9CxCCAHZW4SrlbiziD2
 DzwshuGnpRh8udKAQWNlKQGNq8e8Ybl7yA+uGwsk0GS/GQid9tVAMFU2BEG/pT0I5mpuhMJY
 WX8YTMzdCIPnppPhYBprC4enAxPhUNxxSQHjt7tfgh+/vhoBpq7CSKi1dEbCqT9+iYSKlctR
 0DHzMAr+/m9xK5gaV14By/fz2+C3IuMOVuriTqif79gFy6OFCWCZvvzqNHsVAtdVGFQvrkJG
 DvqJuKtwUmtX0bcP467CGXVehY0Lrqu4tiEvQNHzZ2dWe8afjNVmfBEfpj5UlD9saR5sPt3S
 EBPgb7/bnlRV2pSySxhi/OhNzScJj5Nzbj2W17eOTv/T/oB6YyaeVvmpkjoVnw+FD+zHDJ4+
 77bk1vnpmgO+DSk5ZFtOzFn6LsX/cHFsclTJB3slLXvlettYRYjnlZ/s8vK0s+K33k9X4Ixa
 FbsV0zOq/wFM1wxBkgYAAA==
x-auditid: c1b4fb32-f79016d000001045-44-5707162dbcc3
errors-to: mpls-bounces@ietf.org
x-beenthere: mpls@ietf.org
list-id: Multi-Protocol Label Switching WG <mpls.ietf.org>
x-mailman-version: 2.1.17
list-post: <mailto:mpls@ietf.org>
list-archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
x-original-to: mpls@ietf.org
delivered-to: mpls@ietfa.amsl.com
dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
 t=1460082201; bh=DSgwCGUt+ARccYHRhq3EFD7OtXyIvf3nRsGMRcXA93k=;
 h=From:To:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive:
 List-Post:List-Help:List-Subscribe;
 b=CMq/jU+GOCmU4iAFGK/u8KL4knsh7n1Z30gFyCKfGztKiMi7IZUQ6DuFPlo/hjSfn
 DnpSukuP1u3K1oXL4e3TiAVVdi3Ef2tKLoKdAw+S76/IUZ/1W4arpG4NBWWwcaqcPA
 VhKbL9TeXj7m0MI18A8sISm0M9UdJIWBnp7aiZMg=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B95E9A0D797CD549967CE66EE2C9198B@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
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=3Ddraft-ietf-mpls-residence-time-07


Please note that it may take a couple of minutes from the time of submissio=
n
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

--_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_--