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///XwlCAAEa4AP//vUBw
Date: Wed, 16 Mar 2016 14:23:40 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A0DEE8@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>
In-Reply-To: <56E96B46.1060706@labn.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/XE381ZfMxUWF01XhWDWenRFMHic>
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

Hi Lou,
if node A is on RTM_SET TLV but not in RRO, then its first upstream RTM-cap=
able node, e.g. node B, would set TTL to 255 according to the text. Thus th=
ere will be no RTM processing downstream of node B and all packets will be =
arriving at the egress LER in RTM encapsulation.

	Regards,
		Greg

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
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-reside=
nce-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 calc=
ulation some up too small if the wrong SOs are removed, and wouldn't this r=
esult 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 co=
uld 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 lis=
t, then the TTL will be set to 255 and packet will not be processed by inte=
rmediate RTM-capable nodes but arrive at LSP egress LSR. Thus not all RTM c=
apable 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=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.com>=
 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 support=20
>> of Residence Time Measurement. Would appreciate the confirmation from Lo=
u.
>>
>> =20
>>
>> I don't think I saw a response to:
>>
>>> I think this doesn't always work, e.g., when RRO is modified due to=20
>>> 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=20
>>> the number of non-supporting hops.  I guess it's always possible to=20
>>> 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 until=20
>> 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=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 -- which =
I think then translates to RTM black holes.  Also not covered is what happe=
ns 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 t=
hat 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 impact=
ed due to policy)? -- not saying I like this, I just think it fills the ope=
n 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
>
>> =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-time-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-05
>>
>>> 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 for=20
>>> each
>>>    message allows for a more accurate determination of the delay to=20
>>> 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>
>>> 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
>>
>