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 10:27 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 21A4521F9B8A; Thu, 29 Aug 2013 03:27:12 -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 Kr5GP1oKVUmE; Thu, 29 Aug 2013 03:27:11 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8A21F9CA8; Thu, 29 Aug 2013 03:27:09 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id q58so234827wes.11 for <multiple recipients>; Thu, 29 Aug 2013 03:27:08 -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=12I2Qk2wcGdRuI2OutOi0wUwTaUYNePL/nsso8VHbiA=; b=l8iztrY4b8nYHJAPu4iqImgmE1Z4QHPCqLjneLbF6iK9BdHpwOyaZ+CjzwSl8389eu aBQo4oQ3eaUIhi9QAsdI54/8CWgmLzHaXRnn2pUMB1feX8E0ArKVxgssxPqvIpvpINWG zU7WESvgkP3/nAUXr+R89Md2kmdk+HE+CzgO7UgJillwg9rFHToBslgdKt04Ai/yYSXG j15/xJBZEKJyEtV1Z6xhHk42HUa49eLwHeAknbhEaN2bEkQwh1ymp1afykUUBvfh5JFb P+IBHnyq/ePZs84GrYqPLRmvCvb++vlK1IZ647EGYLZ9KTI85ovGy1CmgY4F06kLDhIl Otkg==
X-Received: by 10.194.109.68 with SMTP id hq4mr4967067wjb.12.1377772028762; Thu, 29 Aug 2013 03:27:08 -0700 (PDT)
Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id i8sm11388391wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 03:27:08 -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> <04cf01cea499$22eb4a80$68c1df80$@gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C285CA@szxeml558-mbs.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C285CA@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 13:24:38 +0300
Message-ID: <04d701cea4a1$f8fdde00$eaf99a00$@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/msuDkJxBc8cYmi4kAJrrZpSAxjw2zQBgMlGEZpzr4RQ
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 10:27:12 -0000
Hi, This text is OK if one wants to implement this draft. My concern was about the consistency of the IANA registration so that if someone defines a new TLV type 1 based on RFC4379, IANA will know that it must update also the registry for TLV type 21. If you see no such problem, I have no concerns Roni > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: 29 August, 2013 1:05 PM > 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, > > How about this: > > " 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 and kept the same > as that for TLV Type 1. All sub-TLVs in these ranges (include existing > and future defined) defined for TLV Type 1 apply to TLV Type 21. > Assignments of sub-..." > > Best regards, > Mach > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Thursday, August 29, 2013 5:21 PM > > To: Mach Chen; > > 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, > > 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
- Gen-ART LC review of draft-ietf-mpls-return-path-… Roni Even
- Re: Gen-ART LC review of draft-ietf-mpls-return-p… Loa Andersson
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Roni Even
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Mach Chen
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Roni Even
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Mach Chen
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Roni Even
- Re: Gen-ART LC review of draft-ietf-mpls-return-p… Loa Andersson
- RE: Gen-ART LC review of draft-ietf-mpls-return-p… Roni Even
- Re: Gen-ART LC review ofdraft-ietf-mpls-return-pa… t.p.
- RE: Gen-ART LC review ofdraft-ietf-mpls-return-pa… Roni Even