Re: [RTG-DIR] [Teas] RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02
"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Sat, 21 February 2015 15:09 UTC
Return-Path: <rgandhi@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8691D1A7012; Sat, 21 Feb 2015 07:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.828
X-Spam-Level:
X-Spam-Status: No, score=-10.828 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 AO2TDno4X0AU; Sat, 21 Feb 2015 07:09:24 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86871A6FF0; Sat, 21 Feb 2015 07:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37878; q=dns/txt; s=iport; t=1424531364; x=1425740964; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=32O0xkOIKIAVMa4ZjA+wHjQIU7IX3R+IXePOdsXmPqQ=; b=YTr8hQ0A4mKI0aZ891lTSGtOsZh2tSTTxvo+bDmqYhFCQnzNvcwysjlp ylal4jwU+NERaXVpPvFfL5mapbKvXkZZhcBS49g5tJ4CMkVRVrvGPRsFg ycok21HFtRZQ6Uo/l5HrUGSSkD6fIq7A7rGMnJpnhqTwHxcptwGY5r8A6 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BECABhn+hU/5pdJa1agkNDUloEgwS+GYFugjiDOQIcfEMBAQEBAQF8hA8BAgQjVhIBCBEDAQIhAQYDAgQfERQJCAIEAQ0FiBsDEQ26bJJ4DYUsAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oRfoJEgX8QCgcKBgECBIJigUMFjV2BcYNchB+BRoEbOIJdiHmCSYM+IoIygTxvAYFDfwEBAQ
X-IronPort-AV: E=Sophos;i="5.09,620,1418083200"; d="scan'208,217";a="394892343"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2015 15:08:59 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1LF8xXs024969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Feb 2015 15:08:59 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 21 Feb 2015 09:08:58 -0600
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: "lizho.jin@gmail.com" <lizho.jin@gmail.com>, teas <teas@ietf.org>, draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp <draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org>
Thread-Topic: [Teas] RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02
Thread-Index: AQHQTClZV8QpAZPuTkidKIUKCqOoRJz7SQsA
Date: Sat, 21 Feb 2015 15:08:58 +0000
Message-ID: <D10E0167.506F4%rgandhi@cisco.com>
In-Reply-To: <201502191749217392692@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.82.209.21]
Content-Type: multipart/alternative; boundary="_000_D10E0167506F4rgandhiciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/L7h7xwqPbyJ9YIrPFgtngBSSGn4>
X-Mailman-Approved-At: Mon, 23 Feb 2015 07:17:10 -0800
Cc: rtg-dir <rtg-dir@ietf.org>, rtg-ads <rtg-ads@tools.ietf.org>
Subject: Re: [RTG-DIR] [Teas] RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2015 15:09:27 -0000
Hi Lizhong, Thank you for reviewing the document and providing your comments. Please see inline .. <RG> .. From: "Lizhong com>" <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>> Date: Thursday, 19 February, 2015 4:49 AM To: teas <teas@ietf.org<mailto:teas@ietf.org>>, draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp <draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org<mailto:draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org>> Cc: rtg-dir <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, teas <teas@ietf.org<mailto:teas@ietf.org>>, rtg-ads <rtg-ads@tools.ietf.org<mailto:rtg-ads@tools.ietf.org>> Subject: Re: [Teas] RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 Sorry, I missed one more comment below: Section 7 Security Considerations [Lizhong] the single side provisioning mode will allow one node to trigger another node to setup LSP. This will introduce some security issue for the remote node. Some administrative police may be introduced to allow/deny others to trigger LSP setup. <RG> Agree, updated in the latest revision (05). ________________________________ Regards Lizhong From: lizho.jin@gmail.com<mailto:lizho.jin@gmail.com> Date: 2015-02-19 17:21 To: teas<mailto:teas@ietf.org>; draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp<mailto:draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp@tools.ietf.org> CC: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; rtg-ads<mailto:rtg-ads@tools.ietf.org>; teas<mailto:teas@ietf.org> Subject: RtgDir Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 Hello I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-02 Reviewer: Lizhong Jin Review Date: 19 February 2015 IETF LC End Date: N/A Intended Status: Standard Track Summary: The document is basically ready for publication. I found some minor issues, and hope to see the clarification. Commnets: I paticipate the initial discussion of this draft. I am lucky to review it again. Overall, the processing rule of independent provisioning hope to be explicitly described. No major issues, some minor issues need to be clarified. <RG> Great, thanks. Major issues: No Minor issues: Section 3.2 In each of the situations described above, both provisioning models are applicable. [Lizhong]: for the second situations above, how could you let the reverse LSP to be existed before the forward LSP for single side provisioning? Wouldn't the reverse LSP trigger another reverse LSP? <RG> Fixed. Section 3.2.1. For the single sided provisioning model, creation of reverse LSP1 is triggered by LSP2 or creation of reverse LSP2 is triggered by LSP1. When creation of reverse LSP2 is triggered by LSP1, LSP1 is provisioned first (or refreshed if LSP1 already exists) at node A. [Lizhong]: LSP1 and LSP2 is in Firgure1? Better to explicitly say that in the document. <RG> Fixed. A similar procedure is used if LSP2 is provisioned first at node B and the creation of reverse LSP1 at node A is either triggered by LSP2 or the reverse LSP1 existed. In all three scenarios, the two unidirectional LSPs are bound together to form an associated bidirectional LSP based on identical (Extended) ASSOCIATION Objects in the two LSPs' Path messages. [Lizhong]: I doubt if the following scenario is realistic in Single Sided Provisioning. LSP2 is provisioned first, reverse LSP1 at node A is existed before LSP2. The what is the Association Type in reverse LSP1? Before LSP2, will the reverse LSP1 trigger another LSP? <RG> Fixed. Section 5. Processing Rules In general, the processing rules for the ASSOCIATION Object are as specified in [RFC4872] and Extended ASSOCIATION Object are specified in [RFC6780]. Following sections describe the rules for processing (Extended) ASSOCIATION and REVERSE_LSP objects for associated bidirectional LSPs. [Lizhong]: across the draft, it is not explicitly saying what is the processing rules for independent provisioning. It is better to say it here or other place. <RG> There are related changes in the latest version of the draft, especially with REVERSE_LSP Object usage. Please advise if like to see anything specific. Section 5.1 (Extended) ASSOCIATION Objects with both single sided and double sided Association Types MUST NOT be added in the same Path message. [Lizhong]: what if two types exist together? Only use the first one? <RG> It says MUST NOT :) Section 5.2 The REVERSE_LSP Object MUST NOT be included in a REVERSE_LSP Object. [Lizhong]: typo here? <RG> The document does not allow nested REVERSE_LSP Objects. Section 5.3 In particular, any object that was copied as part of initial Path message creation MUST be copied when modified. [Lizhong]: not understood "copied when modified", is it "copied after modified"? <RG> Fixed. In both cases, when the egress node receives a PathTear message the node MUST remove the associated reverse LSP using Standard PathTear message processing. Tear down of the reverse LSP for other reasons SHOULD NOT trigger removal of the initiating LSP, but SHOULD result in the egress node sending a PathErr with Error code "Admission Control Failure (01) [RFC2205]" and Sub-code "Reverse LSP Failure" defined in this document. [Lizhong]: the above description is not accurate. What if the egress node have forward LSP down because of local link down? In that case, it will not receive PathTear, it is still need to tear down the reverse LSP? It should say, whenever the forward LSP is down, the reverse LSP SHOULD be removed. <RG> Fixed. Many thanks again, Rakesh Regards Lizhong
- [RTG-DIR] RtgDir Review of draft-ietf-teas-mpls-t… lizho.jin@gmail.com
- Re: [RTG-DIR] RtgDir Review of draft-ietf-teas-mp… lizho.jin@gmail.com
- Re: [RTG-DIR] [Teas] RtgDir Review of draft-ietf-… lizho.jin@gmail.com
- Re: [RTG-DIR] [Teas] RtgDir Review of draft-ietf-… Rakesh Gandhi (rgandhi)
- Re: [RTG-DIR] [Teas] RtgDir Review of draft-ietf-… Rakesh Gandhi (rgandhi)