Re: [mpls] [Teas] I-D Action: draft-ietf-mpls-residence-time-03.txt

Greg,
    See below.

On 2/18/2016 10:58 AM, Gregory Mirsky wrote:
> Hi Lou,
> greatly appreciate your thoughtful comments. We updated the draft and uploaded it as -04. Please find more details in-line and tagged GIM>>.
> Hope we're converging and are really close to completely address your very helpful comments.
>
> 	Best regards,
> 		Greg
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Tuesday, February 16, 2016 3:45 AM
> To: draft-ietf-mpls-residence-time@ietf.org
> Cc: mpls@ietf.org
> Subject: Re: [mpls] I-D Action: draft-ietf-mpls-residence-time-03.txt
>
>  Greg,
>
> Thanks for the changes. I have some  comments on this version:
>
> - I don't think the role of rro is clear in this rev. It references hop count in the narrative, but then has no associated required processing.  I read it as vestigial text that can be dropped, but perhaps not. Either way this should  be clarified.
> GIM>> Added the following sentence towards end of Section 4.6:
> 	The calculated  value is used by the LSR as TTL value in outgoing label to reach the  next RTM capable LSR on the LSP.

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?

> - given that the  RTM_SET Sub-object is no longer carried in the rro, I think it would be clearer to align the name with other LSP attribute TLVs. 
> (See
> http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml)
> . So perhaps RTM_SET TLV and simply RTM_SET for short (and in place of RRSO)?
> GIM>> Thank you, accepted and changed text accordingly.
>
> - The last paragraph of 4.7 needs to be updated to reflect that there isn't a new object being introduced and that RTM_SET is carried as an attribute tlv.
> GIM>> Done.
>
> - there are no processing rules for RTM_SET sub-TLVs.
> GIM>> That is very good point. In reviewing processing of RTM_SET sub-TLVs we agreed that duplicate sub-TLV is indication of misbehaving LSR and cannot be interpreted. Hence we propose to interrupt signaling LSP and generate PathErr with new Error Code. Once decided that we updated processing of duplicate RTM_SET TLV to behave in the similar manner, generate PathErr with distinct new Error Code. Updated IANA Consideration section accordingly to request two new Error Codes.
looks like a good start.  It should say if this is enforced at just
egress or all nodes.  Also it should state what a supporting transit
node is expected to do.  e.g., (put into nice prose):
    A transit node MUST examine an incoming Path Message for the
presence of a RTM_SET TLV
    within the LSP_ATTRIBUTES object. 
    If more than one is found, ...
    If none is found ...
    When one is found, the node MUST include its [FILL_IN] address to
the end of the
    RTM_SET TLV in associated outgoing Path messages.
   etc.

also for Reserved:
    s/transmission/initiation
as transit notes transmit, but shouldn't modify...

Lou
>
> That's it.
>
> Thanks,
> Lou
>
>
>
>
>
>
>
>
> On February 12, 2016 11:47:43 AM internet-drafts@ietf.org wrote:
>
>> 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-03.txt
>> 	Pages           : 25
>> 	Date            : 2016-02-12
>>
>> 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-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-03
>>
>>
>> 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
>>
>
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas