Return-Path: 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 3EEB221F856D for ; Tue, 11 Dec 2012 10:01:18 -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 Kk5l1kNMzErN for ; Tue, 11 Dec 2012 10:01:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1BAA21F8625 for ; Tue, 11 Dec 2012 10:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24524; q=dns/txt; s=iport; t=1355248875; x=1356458475; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fw2ALUp5fsR8l954HUGG9Et+WvAQb/uaA97IQjpRl9I=; b=WGkye7UPiWIhyH0nIsnIqKeracAsElhcQSjN7+U6BwB7xjNwQkZ3A/ve up64dgx/ZAPQ0QDg+mRt4xuTjbtr7lfTa0wfeqgClDsK03tpprPHCycDY LUi8UtMPEJD1B3t/F5xpXSU0WPIVE2zjjXOyzBBLIJbq8zDh56zytg4vx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKBzx1CtJXHA/2dsb2JhbABEgkmpXZIfFnOCHgEBAQQtOhIQAgEIEQQBAQsWBwcyFAkIAgQBDQUIiAkMqw+QYoxKg2JhA6ZPgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="148767793" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 11 Dec 2012 18:01:09 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBBI19lp032389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 18:01:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 12:01:09 -0600 From: "Zafar Ali (zali)" To: "Matt Hartley (mhartley)" , Alan Davey , "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: AQHN05bM5hEWizSVvUep9XzUZOoVq5gUSaWA//+gwoA= Date: Tue, 11 Dec 2012 18:01:08 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC101E3E5A@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC101E3E5A@xmb-rcd-x03.cisco.com> 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_B6585D85A128FD47857D0FD58D8120D3AFAE44xmbrcdx14ciscocom_" MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:01:18 -0000 --_000_B6585D85A128FD47857D0FD58D8120D3AFAE44xmbrcdx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan: I had an offline chat w/ Matt and it will be great if your proposed text ca= n 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@too= ls.ietf.org Cc: 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 o= f RFC 3209 [RFC3209], the processing of SRLG collection for Resv messages m= irrors 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 in= ternal logic will be similar, rather than that the same values will be plac= ed into the Resv RRO as went into the Path RRO? Anyway, yes, I agree with the principle that the SRLGs in the Resv RRO shou= ld also be collected hop-by-hop rather than copied over from the Path RRO a= t the tail. Cheers Matt The benefits of this approach are that - the SRLG information received by the head and tail nodes is cons= istent - 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 +44 (0) 20 8366 1177 network-technologies.metaswitch.com From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@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 Cc: 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 SR= LGs for reverse direction. E.g., consider a use case where an associated no= n-corouted tunnel is used as an FA; forward and reverse directions may foll= ow different paths in the network. When such FA is used as a TE link for th= e tunnel for which SRLG recording is requested, forward and reverse SRLG va= lues would be different. Thanks Regards...Zafar From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@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 Cc: 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 th= e Resv is different to that for the Path. This is unlike the existing proc= essing of RROs, which are handled in the same way for the upstream and down= stream directions (as defined in RFC3209 section 4.4.3). Can you please ex= plain why the collection of SRLGs must be different in the different direct= ions? 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 +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_B6585D85A128FD47857D0FD58D8120D3AFAE44xmbrcdx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan:

 

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

 

Thanks

 

Regards…Zafar

 

From: Matt Har= tley (mhartley)
Sent: Tuesday, December 11, 2012 12:37 PM
To: Alan Davey; Zafar Ali (zali); draft-ietf-ccamp-rsvp-te-srlg-coll= ect@tools.ietf.org
Cc: ccamp@ietf.org; Matt Hartley (mhartley)
Subject: RE: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-col= lect-01

 

Alan,

 

Apologies for the del= ay in responding on this one. Inline:

 

I sugge= st replacing the following paragraph in section 4.1

&n= bsp;

   “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.&nbs= p; Therefore, during the

   forwarding of the Resv message in the upst= ream direction, the SRLG

   information is not needed to be collected = hop by hop.”

&n= bsp;

With th= e paragraph

&n= bsp;

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

&= nbsp;

When y= ou 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?

&= nbsp;

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

&= nbsp;

Cheers=

&= nbsp;

Matt

&n= bsp;

The ben= efits of this approach are that

&n= bsp;

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

&n= bsp;

Regards=

&n= bsp;

Alan Da= vey

&n= bsp;

Netw= ork Technologies Metaswitch Networks

&n= bsp;

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com=

&n= bsp;

&n= bsp;

From: 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
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] A question on draft-ietf-ccamp-rsvp-te-srlg-col= lect-01

 

Alan-

 

There are use cases wh= ere SRLGs for forward direction may not be same as SRLGs for reverse direct= ion. E.g., consider a use case where an associated non-corouted tunnel is used as an FA; forward and reverse directions may follow differe= nt paths in the network. When such FA is used as a TE link for the tunnel f= or 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] On Behalf Of Alan Davey
Sent: Monday, December 03, 2012 12:23 PM
To: 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

 

Authors

 

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

 

According to section 4.1, the c= ollection 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 di= fferent 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

 

<= a href=3D"mailto:alan.davey@metaswitch.com">alan.davey@metaswitc= h.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

--_000_B6585D85A128FD47857D0FD58D8120D3AFAE44xmbrcdx14ciscocom_--