[Gen-art] Gen-ART LC review of draft-ietf-mpls-p2mp-lsp-ping-16
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 31 May 2011 13:00 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BBBE07BF; Tue, 31 May 2011 06:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.366
X-Spam-Level:
X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhcBjudqL6jC; Tue, 31 May 2011 06:00:10 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 61A58E07BA; Tue, 31 May 2011 06:00:10 -0700 (PDT)
Received: from [188.29.122.43] (188.29.122.43.threembb.co.uk [188.29.122.43]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TeTmUwA-ucJk@rufus.isode.com>; Tue, 31 May 2011 14:00:08 +0100
Message-ID: <4DE4E62C.4060805@isode.com>
Date: Tue, 31 May 2011 13:59:24 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: draft-ietf-mpls-p2mp-lsp-ping.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, iesg@ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-mpls-p2mp-lsp-ping-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2011 13:00:15 -0000
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-p2mp-lsp-ping-16 Reviewer: Alexey Melnikov Review Date:2011-05-31 IETF LC End Date: 2011-05-30 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. There are some minor clarity issues (or reviewer confusions) that are worth clarifying. Major issues: none Minor issues: 1.1. Design Considerations As is described in [RFC4379], to avoid potential Denial of Service attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to the control plane. A rate limiter should be applied to the well-known UDP port defined for use by LSP Ping traffic. What is this port? Is mentioning of the port significant? 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [IANA-PORT] that encodes the address family for the Root LSR Address. [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org Which IANA registry do you have in mind? Seeing a link would be helpful. 3.2. Limiting the Scope of Responses The P2MP Responder Identifier TLV only has meaning on an echo request message. If present on an echo response message, it SHOULD be ignored. Are there known reasons for violating the SHOULD? I.e. what are the reasons for having multiple sub-TLVs in the first place? 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs The address in this Sub-TLV SHOULD be of any transit, branch, bud or egress node for that P2MP LSP. Is the use of SHOULD correct here (instead of a MUST)? Are there any choices left if the SHOULD is violated? 3.5. Downstream Detailed Mapping TLV Downstream Detailed Mapping TLV is described in [DDMT]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes for different downstream paths. This functionality can not be achieved via the Downstream Mapping TLV. Are "Downstream Detailed Mapping TLV" and "Downstream Mapping TLV" two different things? As per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in [RFC4379] is being deprecated. 4.1.2. Jittered Responses to Echo Requests Echo response jittering SHOULD be used for P2MP LSPs. If the Echo Jitter TLV is present in an echo request for any other type of LSPs, the responding egress MAY apply the jitter behavior as described here. Can you provide a bit more information about how this work? 4.2.1.1. Responses from Transit and Branch Nodes The presence of a Downstream Detailed Mapping TLV will influence the choice of Return Code. As per [DDMT], the Return Code in the echo response header MAY be set to value TBD ('See DDM TLV for Return Code Am I correct that the value TBD is specified in [DDMT]? If not, it is missing in the IANA Considerations section. and Return SubCode') as defined in [DDMT]. The Return Code for each Downstream Detailed Mapping TLV will depend on the downstream path as described in [DDMT]. 6. OAM and Management Considerations - A MIB module is required for the control and management of LSP Ping operations, and to enable the reported information to be inspected. I think it would be better to be explicit that this document doesn't define such a MIB. 7.2. New TLVs P2MP Responder Identifier TLV (see Section 3.2) is a mandatory What does "mandatory" means in this section? Mandatory for IANA? TLV. Suggested value 11. Four sub-TLVs are defined. - Type 1: IPv4 Egress Address P2MP Responder Identifier - Type 2: IPv6 Egress Address P2MP Responder Identifier - Type 3: IPv4 Node Address P2MP Responder Identifier - Type 4: IPv6 Node Address P2MP Responder Identifier Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested As above. value 12. Nits/editorial comments: 4.3.1. End of Processing for Traceroutes For P2MP TE LSP, the initiating LSR has a priori knowledge about number of egress nodes and their addresses. Hence it possible to Missing "is" after "it". continue processing till a valid response has been received from each end-point, provided the responses can be matched correctly to the egress nodes.
- [Gen-art] Gen-ART LC review of draft-ietf-mpls-p2… Alexey Melnikov
- Re: [Gen-art] Gen-ART LC review of draft-ietf-mpl… Adrian Farrel
- Re: [Gen-art] Gen-ART LC review of draft-ietf-mpl… Alexey Melnikov
- Re: [Gen-art] Gen-ART LC review of draft-ietf-mpl… Adrian Farrel