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

Lou Berger <lberger@labn.net> Wed, 16 March 2016 12:30 UTC

Return-Path: <lberger@labn.net>
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 0C4CC12D69B for <mpls@ietfa.amsl.com>; Wed, 16 Mar 2016 05:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 amKLVHXhIBag for <mpls@ietfa.amsl.com>; Wed, 16 Mar 2016 05:30:07 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 116D612D791 for <mpls@ietf.org>; Wed, 16 Mar 2016 05:30:01 -0700 (PDT)
Received: (qmail 16131 invoked by uid 0); 16 Mar 2016 12:29:59 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 16 Mar 2016 12:29:59 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id WjVj1s00a2SSUrH01jVmH3; Wed, 16 Mar 2016 13:29:56 -0600
X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=0FD05c-RAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=bu8SBMSyS-Fzm1LDTDgA:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:References:To:Subject:From; bh=Rlj7XuKLcjKsjTUNjlnokF9cqXIDr+LJs1+9woRw0lg=; b=RhEvuQNnLDQthyhqxqXEWquAgn mUrPjO1xisTrHCgPPcPq66uLLNUJWdhgY2w+mAinSA3PTBgpudQUjHagjZP8qz4bwBoSFsVwUysYi cEokXjb18vFFYxBktWTUTzfCq;
Received: from box313.bluehost.com ([69.89.31.113]:50678 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <lberger@labn.net>) id 1agAaA-0006Nw-KM; Wed, 16 Mar 2016 06:29:46 -0600
From: Lou Berger <lberger@labn.net>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org
References: <20160315210754.7666.49708.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A0D437@eusaamb103.ericsson.se> <56E88F6B.8010506@labn.net> <7347100B5761DC41A166AC17F22DF11221A0D5AC@eusaamb103.ericsson.se>
Message-ID: <56E951B5.2050803@labn.net>
Date: Wed, 16 Mar 2016 08:29:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A0D5AC@eusaamb103.ericsson.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/AzPT18DqUsOkeyR3SMWX6eLBVFk>
Cc: 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: Wed, 16 Mar 2016 12:30:10 -0000

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-time-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-05
>
> > 
>
> > 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
>