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

Fatai Zhang <zhangfatai@huawei.com> Fri, 14 December 2012 07:01 UTC

Return-Path: <zhangfatai@huawei.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 39A6621F8751 for <ccamp@ietfa.amsl.com>; Thu, 13 Dec 2012 23:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.506
X-Spam-Level: **
X-Spam-Status: No, score=2.506 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 4Q5HhHCiCoFV for <ccamp@ietfa.amsl.com>; Thu, 13 Dec 2012 23:01:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 463BF21F8739 for <ccamp@ietf.org>; Thu, 13 Dec 2012 23:01:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANV15964; Fri, 14 Dec 2012 07:01:28 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 07:00:35 +0000
Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 07:01:21 +0000
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.142]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.003; Fri, 14 Dec 2012 15:01:17 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Alan Davey <Alan.Davey@metaswitch.com>, "Zafar Ali (zali)" <zali@cisco.com>, "Matt Hartley (mhartley)" <mhartley@cisco.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: AQHN2UQyl/SJcH8VQUeUobYsAp340pgX3vjg
Date: Fri, 14 Dec 2012 07:01:16 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF835840516@SZXEML552-MBX.china.huawei.com>
References: <C2EE31C852049D499842B19FC01C0804AF458017@ENFICSMBX1.datcon.co.uk> <B6585D85A128FD47857D0FD58D8120D3ADF2DB@xmb-rcd-x14.cisco.com> <C2EE31C852049D499842B19FC01C0804AF458B31@ENFICSMBX1.datcon.co.uk> <9D50FCE7413E3D4EA5E42331115FB5BC101E3E5A@xmb-rcd-x03.cisco.com> <B6585D85A128FD47857D0FD58D8120D3AFAE44@xmb-rcd-x14.cisco.com> <F82A4B6D50F9464B8EBA55651F541CF83583FE80@SZXEML552-MBX.china.huawei.com> <C2EE31C852049D499842B19FC01C0804AF4648A3@ENFICSMBX1.datcon.co.uk>
In-Reply-To: <C2EE31C852049D499842B19FC01C0804AF4648A3@ENFICSMBX1.datcon.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF835840516SZXEML552MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [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: Fri, 14 Dec 2012 07:01:33 -0000

Hi Alan,

Thanks, I am fine with your proposed text.





Best Regards

Fatai

发件人: Alan Davey [mailto:Alan.Davey@metaswitch.com]
发送时间: 2012年12月13日 23:12
收件人: Fatai Zhang; Zafar Ali (zali); Matt Hartley (mhartley); draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org
抄送: ccamp@ietf.org
主题: RE: [CCAMP] 答复: A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Authors

Thank you all for your feedback.  I have clarified my proposed text and added more text to address Zafar’s point that the SRLGs may differ in the upstream and downstream directions.  Could you please let me know what you think of the following.

I suggest replacing the 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 following.

“When a node receives a Resv message for an LSP for which SRLG Collection is specified, if local policy determines that the SRLG information should not be provided to the endpoints, it MUST return a ResvErr.  Otherwise, it MUST add an SRLG sub-object to the RRO to carry the SRLG information in the upstream direction.  When the Resv message arrives at the head node, the head node can get the SRLG information from the RRO in the same way as the tail node.

Note that a link’s SRLG information for the upstream direction cannot be assumed to be the same as that in the downstream.


-        For Path and Resv messages for a unidirectional LSP, a node SHOULD include SRLG sub-objects in the RRO for the downstream data link only.


-        For Path and Resv messages for a bidirectional LSP, a node SHOULD include SRLG sub-objects in the RRO for both the upstream data link and the downstream data link from the local node.  In this case, the node MUST include the information in the same order for both Path messages and Resv messages.  That is, the SRLG sub-object for the upstream link is added to the RRO before the SRLG sub-object for the downstream link.”


Note that the existing text in section 4.1 on nodes editing SRLG information in an RRO already refers to both Path and Resv messages and therefore needs no change.

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/>




From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: 13 December 2012 06:59
To: Zafar Ali (zali); Matt Hartley (mhartley); Alan Davey; draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] 答复: A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Hi all,

I think the “the processing... mirrors...” may cause confusion or misunderstanding.

To Alan, could you provide some text to refine this sentense?



Best Regards

Fatai

发件人: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] 代表 Zafar Ali (zali)
发送时间: 2012年12月12日 2:01
收件人: Matt Hartley (mhartley); Alan Davey; draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org<mailto:draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org>
抄送: ccamp@ietf.org<mailto:ccamp@ietf.org>
主题: Re: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Alan:

I had an offline chat w/ Matt and it will be great if your proposed text can be clarified based feedback from Matt/ me.

Thanks

Regards…Zafar

From: Matt Hartley (mhartley)
Sent: Tuesday, December 11, 2012 12:37 PM
To: Alan Davey; Zafar Ali (zali); 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>; Matt Hartley (mhartley)
Subject: RE: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-collect-01

Alan,

Apologies for the delay in responding on this one. Inline:

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

When you say, “the processing... mirrors...” I presume you mean that the internal logic will be similar, rather than that the same values will be placed into the Resv RRO as went into the Path RRO?

Anyway, yes, I agree with the principle that the SRLGs in the Resv RRO should also be collected hop-by-hop rather than copied over from the Path RRO at the tail.

Cheers

Matt

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.

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/>


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/>