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

From: Gregory Mirsky <[email-masked]>
Date: Thu, 18 Feb 2016 15:58:54 +0000

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:[email-masked]] 
Sent: Tuesday, February 16, 2016 3:45 AM
To: [email-masked]
Cc: [email-masked]
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.

- 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.

That's it.

Thanks,
Lou

On February 12, 2016 11:47:43 AM [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

Subject: New Version Notification for draft-ietf-mpls-residence-time-04.txt
From: "[email-masked]" <[email-masked]>
To: Alexander Vainshtein <[email-masked]>, Gregory Mirsky <[email-masked]>, Stefano Ruffini <[email-masked]>, John Drake <[email-masked]>, "Sasha Vainshtein" <[email-masked]>, Eric Gray <[email-masked]>, Stewart Bryant <[email-masked]>, Eric Gray <[email-masked]>
Date: Thu, 18 Feb 2016 15:41:30 +0000

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

Name:		draft-ietf-mpls-residence-time
Revision:	04
Title:		Residence Time Measurement in MPLS network
Document date:	2016-02-18
Group:		mpls
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mpls-residence-time-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mpls-residence-time-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-04

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Feb 2016 11:20:39 -0500

Greg,
    See below.

> 	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?

> 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…
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
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 18 Feb 2016 19:50:57 +0000

Hi Lou,
I think we are converging. Please find my answers in-line and tagged GIM2>>.

	Regards,
		Greg

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, February 18, 2016 8:21 AM
To: Gregory Mirsky; [email-masked]
Cc: [email-masked]; CCAMP ([email-masked]); TEAS WG
Subject: Re: [Teas] [mpls] I-D Action: draft-ietf-mpls-residence-time-03.txt

Greg,
    See below.

> 	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?
GIM2>> If the RTM capable LSR cannot calculate the distance to the next downstream RTM capable LSR, then it should set TTL 255. Would that address your concern?
GIM2>> Number of non-supporting RTM nodes - number of TLVs in RRO till matching the Value of the top RTM_SET sub-TLV in RTM-SET.
GIM2>> Yes, calculating or playing TTL game is how the proposed RTM mechanism works. In PCE that may be simpler to do.

> 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)?
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.
GIM2>> Thank you for your help and the text. I believe that by "transit node" we understand "RTM capable LSR". I'll prepare the new version and share with you.

also for Reserved:
    s/transmission/initiation
as transit notes transmit, but shouldn't modify...
GIM2>> Thank you, will change.

Lou