RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

"Roni Even" <ron.even.tlv@gmail.com> Thu, 29 August 2013 09:23 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B0F11E810C; Thu, 29 Aug 2013 02:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCjqZLUbQV-H; Thu, 29 Aug 2013 02:23:57 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9E02B11E8109; Thu, 29 Aug 2013 02:23:56 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id e11so161647wgh.33 for <multiple recipients>; Thu, 29 Aug 2013 02:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Tgj7/CB4UuBexTphdsz6va6OccZY4hz9+AIA+fSYiV4=; b=JBqEdgQU2mXnbcXgOKEBEZYQ6pGHrnmM10IrymaRzjqH36lVFMgSRBSf+TcET17GMl qpHhtQZH3MHnzfHjrsL0zqvX/0YdaoTZu0DRPSyvTC6KsPkIEK8ZE+FFGCeoC9qdAeoi U19M3gsJyt2BBGaZWST67rnE95TvUuIxZ1sfgrdwRPFk+UVjwd+y4VF3aNG9j9XCug3q T46wv1BpwMB1JhMz8NiDQX9lLQH5cRqP3CSsDekv3IHfEKuus1DwwHhD6R20cqZ0W9NU gBg68swPYIpgd6F2e4Ao8jDUgiagQQqkgeis13EmlIJolcxfc20OnQuyWJBnCnomzGyz 1mJQ==
X-Received: by 10.194.176.163 with SMTP id cj3mr4408016wjc.8.1377768233925; Thu, 29 Aug 2013 02:23:53 -0700 (PDT)
Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id mb7sm10953960wic.10.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 02:23:53 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Mach Chen' <mach.chen@huawei.com>, draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C28238@szxeml558-mbs.china.huawei.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C284D5@szxeml558-mbs.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C284D5@szxeml558-mbs.china.huawei.com>
Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Date: Thu, 29 Aug 2013 12:21:23 +0300
Message-ID: <04cf01cea499$22eb4a80$68c1df80$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFOtCz/kupT/msuDkJxBc8cYmi4kAJrrZpSmphrvgA=
Content-Language: en-us
Cc: gen-art@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 09:23:58 -0000

Hi,
I am not sure you responded to my latest email.

Having the policy for TLV type 1 here is not enough in my view since I only
look at RFC4379 and create a new TLV type I will not know that I have to
register it also for the type 21 if it will not be mentioned

As for the vendor specific see my other email
Roni

> -----Original Message-----
> From: Mach Chen [mailto:mach.chen@huawei.com]
> Sent: 29 August, 2013 11:33 AM
> To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
> ping.all@tools.ietf.org
> Cc: ietf@ietf.org; gen-art@ietf.org
> Subject: RE: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
> ping-12
> 
> Hi Roni,
> 
> Thanks for your detailed review and comments!
> 
> Please see my reply inline...
> 
> > From: Roni Even [mailto:ron.even.tlv@gmail.com]
> > Sent: Wednesday, August 28, 2013 9:06 PM
> > To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org
> > Cc: ietf@ietf.org; gen-art@ietf.org
> > Subject: Gen-ART LC review of
> > draft-ietf-mpls-return-path-specified-lsp-ping-12
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> > Document: draft-ietf-mpls-return-path-specified-lsp-ping-12
> > Reviewer: Roni Even
> > Review Date:2013-8-28
> > IETF LC End Date: 2013-9-4
> > IESG Telechat date:
> >
> > Summary: This draft is almost ready for publication as a standard track
RFC.
> >
> >
> > Major issues:
> > Minor issues:
> > I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is
> > defined for TLV type 1 do they need also to be added to TLV type 21.
> > This should be clear, and if there is some relation I think it should
> > be reflected in the IANA registry for TLV type 1
> 
> Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for
> type TLV 1. And in Section 3.3, it has already stated this, it says:
> 
> "The Target FEC sub-TLVs defined in [RFC4379] provide a good way to
>    identify a specific return path.  The Reply Path TLV can carry any
>    sub-TLV defined for use in the Target FEC Stack TLV that can be
>    registered."
> 
> So, for Section 6.2, to make it cleaner and more explicit, how about this
> change:
> 
> Old:
> 
> " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
>    are made directly for TLV Type 21, sub-TLVs in these ranges are
>    copied from the assignments made for TLV Type 1. Assignments of
sub-..."
> 
> New:
> 
> " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
>    are made directly for TLV Type 21, sub-TLVs in these ranges are
>    copied from the assignments (including existing and future allocations)
>    made for TLV Type 1. Assignments of sub-..."
> 
> 
> > 2. For the vendor or private use why a difference policy than the rest
> > of the sub-TLV registry
> 
> This document does not make any changes to the "Vendor and Private use"
> definition, range and policy as defined in RFC4379. In RFC4379, it's
policy is
> defined different from other ranges.
> 
> >
> > Nits/editorial comments:
> > 1. In section 3.4 I assume that "TC" is traffic class. It will be good
> > to expand and have reference.
> 
> OK, will fix it when all last call comments received.
> 
> Best regards,
> Mach