Re: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

"Zafar Ali (zali)" <zali@cisco.com> Tue, 11 December 2012 15:50 UTC

Return-Path: <zali@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196D21F8473 for <ccamp@ietfa.amsl.com>; Tue, 11 Dec 2012 07:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 u9Jsa9-1kP1i for <ccamp@ietfa.amsl.com>; Tue, 11 Dec 2012 07:50:29 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2597821F887A for <ccamp@ietf.org>; Tue, 11 Dec 2012 07:50:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25005; q=dns/txt; s=iport; t=1355241029; x=1356450629; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xu1u6OGyIWkRR0VE3u6nIPKHs2h/XuK5RsBYwfL8jbo=; b=dObwCbgbulTESugUFYdJv/wzpe//6r+kCTK/KAAqmut2K6/0b0dHnsny gKeaYrIthW0BS/CJNc/ONMr7PvPw/XEJf4iwopNvAk13KjqFxdiq7ijCd 4Az/ckTtV16JsT1LFOsHHhxrLKJF46faJR27KzfN5hcbhYQT7MbO2XKpL I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAMJVx1CtJV2c/2dsb2JhbABFgkmpXZIfFnOCHgEBAQQtOhIQAgEIEQQBAQsWBwcyFAkIAgQBDQUIiAkMqmaQa4xKg2JhA6ZPgnOCIg
X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151731808"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 11 Dec 2012 15:50:28 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBBFoRvY007190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 15:50:27 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 09:50:26 -0600
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Alan Davey <Alan.Davey@metaswitch.com>, "draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org" <draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org>
Thread-Topic: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01
Thread-Index: AQHN05bM5hEWizSVvUep9XzUZOoVq5gTxIKA
Date: Tue, 11 Dec 2012 15:50:26 +0000
Message-ID: <B6585D85A128FD47857D0FD58D8120D3AFABD2@xmb-rcd-x14.cisco.com>
References: <C2EE31C852049D499842B19FC01C0804AF458017@ENFICSMBX1.datcon.co.uk> <B6585D85A128FD47857D0FD58D8120D3ADF2DB@xmb-rcd-x14.cisco.com> <C2EE31C852049D499842B19FC01C0804AF458B31@ENFICSMBX1.datcon.co.uk>
In-Reply-To: <C2EE31C852049D499842B19FC01C0804AF458B31@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.244.93]
Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D3AFABD2xmbrcdx14ciscocom_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 15:50:42 -0000

Hi Alan:

Please see in-line.

Thanks

Regards...Zafar

From: Alan Davey [mailto:Alan.Davey@metaswitch.com]
Sent: Thursday, December 06, 2012 4:48 AM
To: Zafar Ali (zali); draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Hi Zafar

Thanks for your response.  However, I am considering only the SRLG collection for a single LSP.  Collection of SRLGs for associated bi-directional LSPs and how the collection may be presented to other layers is orthogonal to this discussion.

No it is not orthogonal to this discussion. It is very much related. Please consider a bi-directional non-corouted  TE link is used as an FA/ RA for an LSP who's SRLG info is being recording. So we cannot assume forward and reverse SRLGs are *always* the same - and why assume when we don't have to make such assumption.

I still have a doubt about the collection of SRLG information in the Resv message.  Unless there is a reason not to, I think that the collection should be handled in the same way in both the upstream and downstream directions.  Please let me know what you think of the following suggested change to the draft.

I suggest replacing the following paragraph in section 4.1

   "Before the Resv message is sent to the upstream node, the tail node
   adds an SRLG sub-object to the RRO.  The collected SRLG information
   can be carried in the SRLG sub-object.  Therefore, during the
   forwarding of the Resv message in the upstream direction, the SRLG
   information is not needed to be collected hop by hop."

With the paragraph

"As in the procedures defined for the processing of RROs in Section 4.4.3 of RFC 3209 [RFC3209], the processing of SRLG collection for Resv messages mirrors that of the Path messages.  That is, each intermediate node adds an SRLG sub-object to the RRO."

My point is that we should NOT mirror SRLG values from Path RRP to Resv RRO. We should just record SRLG values for the reverse direction of the link in Resv RRO. Similarly, SRLGs of forward direction on the link in Path RRO. The collection should happen on hop-by-hop basis for both path and resv RRO.

The benefits of this approach are that

-          the SRLG information received by the head and tail nodes is consistent
-          no information is lost when the SRLG information is collected in the Resv, it still includes a hop to SRLG mapping.

I agree that the collection should happen on hop-by-hop basis for both path and resv RRO.

oatetwork Technologies
Metaswitch Networks

alan.davey@metaswitch.com<mailto:alan.davey@metaswitch.com>
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<http://network-technologies.metaswitch.com/>


From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 03 December 2012 17:36
To: Alan Davey; draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org<mailto:draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Alan-

There are use cases where SRLGs for forward direction may not be same as SRLGs for reverse direction. E.g., consider a use case where an associated non-corouted tunnel is used as an FA; forward and reverse directions may follow different paths in the network. When such FA is used as a TE link for the tunnel for which SRLG recording is requested, forward and reverse SRLG values would be different.

Thanks

Regards...Zafar

From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Monday, December 03, 2012 12:23 PM
To: draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org<mailto:draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org>
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Authors

I have a doubt about draft-ietf-ccamp-rsvp-te-srlg-collect-01, specifically about the SRLG collection.  Could you please let me know what you think?

According to section 4.1, the collection of SRLG information in RROs for the Resv is different to that for the Path.  This is unlike the existing processing of RROs, which are handled in the same way for the upstream and downstream directions (as defined in RFC3209 section 4.4.3).  Can you please explain why the collection of SRLGs must be different in the different directions?  My preference is that SRLG information collection in RROs is handled in the same way as existing RRO processing.

Regards

Alan Davey


Network Technologies
Metaswitch Networks

alan.davey@metaswitch.com<mailto:alan.davey@metaswitch.com>
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<http://network-technologies.metaswitch.com/>