[mpls] Questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08
zheng.zhi@zte.com.cn Fri, 04 March 2011 07:02 UTC
Return-Path: <zheng.zhi@zte.com.cn>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85ECE3A68B8 for <mpls@core3.amsl.com>; Thu, 3 Mar 2011 23:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.838
X-Spam-Level:
X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KYndOzb+uWI for <mpls@core3.amsl.com>; Thu, 3 Mar 2011 23:02:23 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6AB9B3A67AE for <mpls@ietf.org>; Thu, 3 Mar 2011 23:02:22 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 20595806486374; Fri, 4 Mar 2011 14:58:20 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.4699248914; Fri, 4 Mar 2011 14:55:21 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p246tB4M006348; Fri, 4 Mar 2011 14:55:12 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn)
To: nitinb@juniper.net, kireeti@juniper.net, swallow@cisco.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFA12DDF59.CEB8C16C-ON48257849.002487B0-48257849.00265CED@zte.com.cn>
From: zheng.zhi@zte.com.cn
Date: Fri, 04 Mar 2011 14:52:02 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-04 14:55:12, Serialize complete at 2011-03-04 14:55:12
Content-Type: multipart/alternative; boundary="=_alternative 00265CEA48257849_="
X-MAIL: mse01.zte.com.cn p246tB4M006348
Cc: mpls@ietf.org
Subject: [mpls] Questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 04 Mar 2011 07:02:28 -0000
Dear authors, I have some questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08. 1. In the specified paragraph following "Remote peer addrss" in Section 3.3.3, there is an example described as "E.g. In the LDP over RSVP case Figure 1, router B would respond back with the address of router D as the remote peer address for the LDP FEC being traced." The Figure 1 mentioned is: A B C D E o -------- o -------- o --------- o --------- o \_____/ | \______/ \______/ | \______/ LDP | RSVP RSVP | LDP | | \____________________/ LDP According to the usage described in this draft, there is no FEC Stack change sub-TLV for the LDP FEC being traced. And, there will be only one FEC Stack change sub-TLV, for the RSVP FEC. In this example, does it mean that the remote peer address for the LDP FEC will be included in the FEC Stack change sub-TLV for the RSVP FEC? I don't believe this implementation is suitable, or maybe this example is not suitable here. How to use this remote peer address field exactly? IMHO, the Remote Peer Address is for the build of a LSP topology. However, if without this field in the FEC Stack change sub-TLV, there is no impact on the normal tracing procedures, and the LSP topology will also be build with the information from the other field in FEC Stack change sub-TLVs. 2. AFAIK, the FEC Stack change sub-TLV in the echo reply message is for the initiator to have a knowledge of the Target FEC change. As described in RFC4379 and draft-ietf-mpls-p2mp-lsp-ping-15, the initiator SHOULD copy the Downstream Detailed Mapping TLV into its next echo request. That means the FEC Stack change sub-TLV in the DDM TLV will be also in the next echo request message. I don't think the reciever need this sub-TLV in the echo request. So IMHO it is not necessary to contain this sub-TLV in the echo request message. 3. In the algorithm section 4.3.1.2, there missing a "{" at the end of line fourth " while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) " Thanks, Zhi -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.