[mpls] Review of draft-ietf-mpls-lsp-ping-relay-reply-07
"Nobo Akiya" <nobo.akiya.dev@gmail.com> Sat, 21 March 2015 22:52 UTC
Return-Path: <nobo.akiya.dev@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6F61A904E for <mpls@ietfa.amsl.com>; Sat, 21 Mar 2015 15:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 B76t5lixcqwD for <mpls@ietfa.amsl.com>; Sat, 21 Mar 2015 15:52:10 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491711A9054 for <mpls@ietf.org>; Sat, 21 Mar 2015 15:52:10 -0700 (PDT)
Received: by oier21 with SMTP id r21so116329742oie.1 for <mpls@ietf.org>; Sat, 21 Mar 2015 15:52:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=Y/vErgoPcqgpaWuU4b/nPmfwrl4QzfgXPCi3f0wcZdg=; b=013IZNUSLHGqAQUNu2hiXSNI5MPrLiqgVIVyXutM2KOEVHvt50xZfanmSvlzllSndK D4VxyQ4iah8j0wtQjjilIoJfMMYlq5+6QpClDAtB1YsdOgPZVO/ymNZJsFaWtWCxc7NI O+z0DQd5vP/ktQG6HLVzRTO989FjVbAQAs5wlZ50ec7SNiJM9peWvFDJldedW8H3uNpM P/FmDa/Kta35oARGClC+qE8HqQMKJ/dVaZ9nJv8nHA6scf6bawlDhwQGI8bzk0qo958M Jw8l+UPKzQToYJzlM3Yu1CbVo3b2dHPgCIVeiB6CRjkQC2sneaCHVt20CFku8z4TwQr8 LXmg==
X-Received: by 10.202.87.215 with SMTP id l206mr44230222oib.84.1426978329790; Sat, 21 Mar 2015 15:52:09 -0700 (PDT)
Received: from NoboAkiyaPC (ip-64-134-6-222.public.wayport.net. [64.134.6.222]) by mx.google.com with ESMTPSA id h10sm5126802obx.0.2015.03.21.15.52.07 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Mar 2015 15:52:08 -0700 (PDT)
From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org
Date: Sat, 21 Mar 2015 17:52:03 -0500
Message-ID: <000001d06429$a7dc6520$f7952f60$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdBjnp/Uffs6AUQ+RN6xGntW4OTS5w==
Content-Language: en-ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/pBLSfia7Td_Y7a3nUMdvokUTwRI>
Cc: mpls@ietf.org
Subject: [mpls] Review of draft-ietf-mpls-lsp-ping-relay-reply-07
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 21 Mar 2015 22:52:13 -0000
Hi Authors, I was asked to provide a review of the following document: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-07 The document is well written and addresses a real problem. I do have a number of (mostly minor and some moderate) comments which I'd like to see addressed before progressing the document. Section 2 -------------- Figure 1 demonstrates a case where one LSP is set up between PE1 and PE2. If PE1's IP address is not distributed to AS2, a traceroute from PE1 directed to PE2 could fail if the fault exists somewhere between ASBR2 and PE2. Above is not entirely accurate. The Traceroute from PE1 to PE2 can fail even if there is no fault. It would be good to clarify this by saying "If PE1's IP address is not distributed to AS2, a traceroute from PE1 directed towards PE2 can result in a failure because an LSR in AS2 may not be able to send the Echo Reply message". Note that throughout the document, routable address means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS Missing '.' (period) at the end of the paragraph. When tracing an LSP from one AN to the remote AN, the LSR1/LSR2 node could not make a response to the Echo Request either, like the P2 node in the inter-AS scenario in Figure 1. "... could not make a response to the Echo Request either ..." can perhaps be rephrased as "... cannot send the Echo Reply either ...", to be a bit more clear. Yeah it's really a nitpick, but _making_ the response packet and _sending_ the response packet are two different operations in a code. Figure 3 -------------- Typically, the numbers at the top (i.e., bit positions 0, 1, 2, ...) are aligned with columns with '-' character instead of '+' character. In other words, let's shift the bit positions to the right by one space. Section 3.3 -------------- s/the Reply/the Echo Reply/ Section 4.1 -------------- When the Echo Request is first sent by the initiator included a Relay Node Address Stack TLV, the TLV MUST contain the initiator address as the only entry of the stack of relayed addresses, I'd like to suggest rephrasing the first half of above sentence as follows. When the initiator sends the first Echo Request for the Traceroute operation, with a Relay Node Address Stack TLV, the TLV MUST contain ... Section 4.2 -------------- Those address entries with K bit set to 1 MUST be kept in the stack. The receiver MUST check the addresses of the stack in sequence from bottom to top to find the last address in the stack with the K bit set (or the top of the stack if no K bit was found). Shouldn't above "find the last address in the stack with the K bit set" instead say "find the last non-Null address in the stack with the K bit set"? Otherwise the procedure will cause relay LSRs to always refer to this Null address with K bit set, preventing the first initiator address to be ever reached when searching for the next relay address. On a related topic, what is the purpose of allowing a Null address entry with K bit set? If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to nodes in the other domain, s/may not be able to nodes/may not be able to reach nodes/ If a node spans two addressing domains (with respect to this message) where nodes on either side may not be able to nodes in the other domain, then the final address added MUST set the K bit. Above procedures defines a strict operation (i.e., MUST) for the K bit usage. However, how an LSR determines "If a node spans two addressing domains where nodes on either side may not be ..." is very vague. It might be possible that we can end up with different implementations of the K bit setting because of this vagueness. What's your thoughts? If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV MUST be returned back in the Echo Reply message. Some other TLV(s) MUST be dropped. Well, it's possible that the Relay Node Address Stack TLV has grown so big and that is the only optional TLV to be included in the Echo Reply. In that case, the Relay Node Address Stack TLV cannot be included despite the "MUST". I believe what you are trying to imply here is that the Relay Node Address Stack TLV takes precedence over other optional TLVs, when determining which optional TLVs to keep in the Echo Reply. In that case, perhaps it is better to say "If the full reply message would exceed the MTU size, the Relay Node Address Stack TLV SHOULD be included in the Echo Reply message (i.e., other optional TLVs are excluded)." Section 4.3 -------------- The Destination Address determined in section 4.2 is used as the next relay node address. Section 4.2 only describes how to update the Relay Node Address Stack TLV. It also specifies how to update the Destination Address Pointer field. However, nowhere in section 4.2 talk about how the Destination Address is determined. I'm assuming "the Destination Address determined ..." is referring to this address which the Destination Address Pointer is pointing to. Perhaps it'll be a good idea, somewhere in section 4.2, to say "... _this_ address is determined to be the Destination Address". Section 4.4 -------------- Upon receiving an Relayed Echo Reply message with its own address as the destination address in the IP header, the relay node MUST determine the next relay node address as described in section 4.3, with the modification that the location of the received Destination Address is used instead of the bottom of stack in the algorithm. In above, I think you meant section 4.2 instead of section 4.3. The destination address in Relay Node Address Stack TLV will be updated with the next relay node address. By "destination address" above, do you mean the Destination Address Pointer field? If so, a bit of clarification is required. Otherwise, I'm not sure what you mean by "destination address" above. The document is not very clear on how these two fields are used. - Source IP address field of the IP header - Source Address of Replying Router field of the Relay Node Address Stack TLV I'd imagine you'd want one field to be set by the egress LSR and unmodified by every upstream relay LSRs, and one field to be updated by the egress LSR and every upstream relay LSR. This is sort of clarified in section 4.7, but really should be part of the procedures. Section 4.6 -------------- During a traceroute operation, multiple Echo Request messages are sent. Each time the TTL is increased, the initiator MUST copy the Relay Node Address Stack TLV received in the previous Echo Reply to the next Echo Request. True but don't we want the initiator to "reset" some fields such as Reply Add Type, Source Address of Replying Router and Destination Address Pointer? Section 6 -------------- As an added security, a receiver of an MPLS Echo Request should verify that the first address in the Relay Node Address Stack TLV is the same address as the source IP address field of the received IP header. Thanks! -Nobo
- [mpls] Review of draft-ietf-mpls-lsp-ping-relay-r… Nobo Akiya
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-rel… lizho.jin@gmail.com
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-rel… Nobo Akiya
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-rel… lizho.jin@gmail.com
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-rel… Nobo Akiya
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-rel… lizho.jin@gmail.com