[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.