From nobody Sat Jan 3 03:53:04 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE651A1A40 for ; Sat, 3 Jan 2015 03:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 PEtN61Me5VLv for ; Sat, 3 Jan 2015 03:53:01 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD531A1A3A for ; Sat, 3 Jan 2015 03:53:00 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03BqwcS010095; Sat, 3 Jan 2015 11:52:58 GMT Received: from 950129200 (089144211041.atnat0020.highway.a1.net [89.144.211.41]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03Bqvrq010073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2015 11:52:58 GMT From: "Adrian Farrel" To: Date: Sat, 3 Jan 2015 11:52:58 -0000 Message-ID: <012001d0274b$d25f3630$771da290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAnS4NDd8E3HP9wRBipfqBkWR+FAA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21220.006 X-TM-AS-Result: No--11.598-10.0-31-10 X-imss-scan-details: No--11.598-10.0-31-10 X-TMASE-MatchedRID: cBC9vYB2TnenykMun0J1wnBRIrj8R47FtZirJiseCcprE1c4mB5UmiG6 /1cZ3ZJyHnf+3jZcxtO5NR8METv0p85/oVSv8cmRYr99ImIZafjVKWIReh1hPWecrqZc3vabEoB 7CD3tV5js7975EykgpdFOMCgRx26cCCk23kSAVszzh2yKdnl7WB0PsyMp50OODuLvUF8m+VYQYF VJiK7fhRAyZ2ulGxhKmiWlXNGhtSTpw2ocrkGyOFaA5UKX+E3VkT7cMJfe6JvD3h2nmZ4BQTXUi jVP08TcWr5dtyB7J8a9Sk0l35T/M8lBBl8WJYU/3FqOVb7PDELAWTziWGaDPA4AepdqPBUYX1VY 9tu3l+7CO/bPEe/mBSmweSd1jOH7kXzLvY34GjTDa1qWPNOExr4X/8yfdrbDSGRgeGWjOKJIBU7 6nhg21upPNpp8UgMteQXtxYrntfAkmsb/+g5E0uDrPgZsoxLtgHzgwy8qV5oHWPn2mj7oRBkdi8 WIojRfbJCo1WqDM7KJjZ8jx/XaFReyFjU4TCuH6/xAZojbl7c6En2bnefhoEFF7QZ35lZ3pZ5y5 V+4l8SSSTQ9Kx5Wcf/MWe7Pn9Jm7vEPgLSbfiCeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0eP s7A07cjHchynrO5b/NC/K9M0jLtUBuGjpGcbchTRTLYivNdYIjuaqw2T4Gs= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/TuqNHHu9EnotWJv0hdLq3JZU-Dk Cc: teas@ietf.org Subject: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 11:53:03 -0000 Hi authors, Thanks for this document, the first from TEAS to reach me for publication. I found it to be a simple and clear read. The IANA section is clear and well-written. I have done my usual AD review with the intent to catch any remaining issues before issuing IETF last call. I think my first three points need discussion with the working group. The remaining points are relatively small. While I wait for your discussion or a new revision, I'll put the draft into "Revised I-D Needed" state. Thanks for your work, Adrian --- Section 2.3 needs to describe the processing when an ERO Hop Attributes subobject is encountered after a loose hop subobject or a strict hop that is an abstract node? - Is it valid? - Is it assumed to apply to all hops in that loose hop or abstract node? - Or in the case of a loose hop, does it just apply to the named hop itself? - What about if the preceding subobject is an interface identifier or a label? I wonder whether reference to 4990 would help at all. Note that 3.2 seems to handle all the options for use in the RRO. --- 3.2.1 has All such subobjects MUST be forwarded unmodified by transit LSRs. That is, of course, the general rule, but I assume that there are exceptions. For example, an ASBR may choose to prune the information that is forwarded in an RRO. Similarly, the UNI-N may strip information. I think the point would be that "If a node forwards an RRO subobject for a specific hop, it MUST forward any associated HOP Attributes subobjects." But even this may be too restrictive for a border node that wants to report the chosen path but not expose how the internals of its network are operated. In this case it may want to strip HOP Attributes subobjects from the RRO or even modify them to mask information. Can you add some clarification about all of this? --- I think section 5 is a little optimistic. You are introducing a new mechanism for the control of the behavior on certain nodes on the path of the LSP. Since the control of those nodes may impact the behavior of other LSPs passing the node, some care is needed. For example, setting optical power levels for one lambda can interfere with the signals on other lambdas. Thus, and in general, you have a mechanism that takes control away from the node itself and puts it in the hand of the node that signaled the LSP. This opens up three security possibilities: 1. Simple errors in the attributes of an LSP may inadvertently impact existing LSPs while still allowing this LSP to be set up. 2. A malign ingress may signal an LSP down a path and with attributes chosen to damage other LSPs from other ingresses. 3. An attacked Path message may result in damage to other LSPs. The third of these is mitigated somewhat by existing RSVP-TE security mechanisms. The first two (and the third in the case of a subverted node) can only be mitigated by allowing policy to be applied at a node that implements the HOP Attributes it receives in an ERO. A node must be allowed to determine that satisfy the attributes would be inadvisable or against local policy even if practically possible. In these cases the node has a choice to either reject the Path message (but a new error code might be helpful) or to modify the requested attribute (but in this case it might be required to report exactly what it has done, presumably in the RRO). === Please don't "propose". You intend this document to be published as an RFC, so you should "define". --- 3.1 has Attributes TLVs The processed or addition HOP Attributes, using the format defined in Section 2.2 . Trying to parse this, I think you mean s/addition/additional/ --- 3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder what the exception cases are: under what circumstances MAY an implementation vary from these rules? --- In section 4.2, do you want to add a request to IANA to use the same value as assigned in 4.1? From nobody Sat Jan 3 06:34:22 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A830B1A8A10 for ; Sat, 3 Jan 2015 06:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 J_F9UDxLz_IN for ; Sat, 3 Jan 2015 06:34:18 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF9C1A8A0D for ; Sat, 3 Jan 2015 06:34:18 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03EYGHE007940; Sat, 3 Jan 2015 14:34:16 GMT Received: from 950129200 (089144224044.atnat0033.highway.a1.net [89.144.224.44]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t03EYEUd007914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 3 Jan 2015 14:34:15 GMT From: "Adrian Farrel" To: Date: Sat, 3 Jan 2015 14:34:14 -0000 Message-ID: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAnYhVCF4WqjWyETKKYnD4PKpwBSg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.000 X-TM-AS-Result: No--12.749-10.0-31-10 X-imss-scan-details: No--12.749-10.0-31-10 X-TMASE-MatchedRID: IY5u7cNKvgOzOchXTgjX0biMC5wdwKqd7yWPaQc4INTIs4CjQ/C5uWAh JwKJaQoQOALXx87XGhbY/FoqAB0MSP/8zeX9WucycFEiuPxHjsXj5lyuq8IOQaj5v7I4/SgYYID 9Y+Lh/TzfYGIa9wgZ2Ad04/lAg4mPrxpSystEXJK8coKUcaOOvVAsG9fXVGlJV6KWY8jugmVUxe qfMZiM0R7Lv8o5WLDJKISk8WdGcXCfKvWkXoMtxEhEDfw/93BuJ7TAdoWYpOcFt5BIjeJMn5xak 1lKPxhNhWi4pSZYsD9kVsT9kFXv01xxDx5qbkR9OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAq rjYtFiQwf0sA6n+ddCRF4Y0DM0DfBEPDJFqPwuKgkfVoS9cUgX7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/teas/vkNqf02QubHRlbT54WGno3olvP8 Cc: teas@ietf.org Subject: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 14:34:20 -0000 Thank you for recognising the use of the Administratively Down bit for LI. It's good to see existing mechanisms being adapted to new uses. I've done my usual AD review to try to catch any issues before IETF last call. I've found a few issues, the first two of which will need discussion in the working group, I think. The remaining issues are relatively minor. While we wait for you to discuss these issues and possibly issue a new revision, I will put the document into "Revised I-D Needed" state. Thanks for the work, Adrian --- You want to use a bit in the Attribute Flags TLV to indicate Loopback and propose including that TLV in the HOP Attributes ERO subobject as defined in draft-ietf-ccamp-lsp-attribute-ro. Please note that that draft is now draft-ietf-teas-lsp-attribute-ro. However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags TLV is not allowed in the HOP Attributes ERO subobject. I think this is for a good reason that many (all?) of bits defined so far have no meaning if targeted at a specific transit LSR. --- I think you need to describe what happens if a LB instruction is received when the LSP is not admin down. Similarly, what happens when an LSP is moved from admin down to admin up when a LB instruction is in force. Is there an implication that transit nodes need to inspect the Admin Status flags? ====== idnits shows == Unused Reference: 'RFC4783' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC4974' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5852' is defined on line 324, but no explicit reference was found in the text --- In 3.2 you talk about reporting the LB in the RRO on the corresponding Resv. What about the RRO on the Path that is forwarded downstream? --- I think that Section 5 should refer to the security considerations section of draft-ietf-teas-lsp-attribute-ro to pick up any concerns with the use of that mechanism. From nobody Mon Jan 5 18:36:34 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09101A038F for ; Mon, 5 Jan 2015 18:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gnWskVKnoQff for ; Mon, 5 Jan 2015 18:36:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EFF1A037A for ; Mon, 5 Jan 2015 18:36:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNP86413; Tue, 06 Jan 2015 02:36:28 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 Jan 2015 02:36:27 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 6 Jan 2015 10:36:24 +0800 From: "Dongjie (Jimmy)" To: "adrian@olddog.co.uk" , "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" Thread-Topic: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Thread-Index: AdAnYhVCF4WqjWyETKKYnD4PKpwBSgB8CmtQ Date: Tue, 6 Jan 2015 02:36:23 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> In-Reply-To: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/pV2INy5JfR9606Jx1uBaWKh75YE Cc: "teas@ietf.org" Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 02:36:32 -0000 Dear Adrian,=20 Thanks a lot for your review, please see my replies inline. > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, January 03, 2015 10:34 PM > To: draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org > Cc: teas@ietf.org > Subject: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb >=20 > Thank you for recognising the use of the Administratively Down bit for LI= . It's > good to see existing mechanisms being adapted to new uses. >=20 > I've done my usual AD review to try to catch any issues before IETF last = call. I've > found a few issues, the first two of which will need discussion in the wo= rking > group, I think. The remaining issues are relatively minor. >=20 > While we wait for you to discuss these issues and possibly issue a new re= vision, I > will put the document into "Revised I-D Needed" state. >=20 > Thanks for the work, > Adrian >=20 > --- >=20 > You want to use a bit in the Attribute Flags TLV to indicate Loopback and > propose including that TLV in the HOP Attributes ERO subobject as defined= in > draft-ietf-ccamp-lsp-attribute-ro. >=20 > Please note that that draft is now draft-ietf-teas-lsp-attribute-ro. Thanks for pointing out this, will update the reference in a new revision.= =20 > However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Fla= gs TLV is > not allowed in the HOP Attributes ERO subobject. I think this is for a go= od > reason that many (all?) of bits defined so far have no meaning if targete= d at a > specific transit LSR. I guess there may be some confusion about this. Section 5.3.1 of draft-ietf= -teas-lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, wh= ich says it is "Allowed on LSP attribute ERO subobject". And in section 5.1= , the "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute Subob= ject", thus my understanding is that the "Attributes Flags TLV" is allowed = in the "ERO HOP Attribute subobject".=20 > I think you need to describe what happens if a LB instruction is received= when > the LSP is not admin down. Similarly, what happens when an LSP is moved f= rom > admin down to admin up when a LB instruction is in force. Is there an > implication that transit nodes need to inspect the Admin Status flags? Agree that we can add some description about these cases.=20 Since the lock and loopback requests are originated by the ingress node, ma= ybe we can specify that the ingress node must not send LB instruction befor= e putting the LSP into admin down state, also must not move the lsp to admi= n up when the lsp is in still loopback mode? For the transit nodes, my understanding is they could inspect the Admin Sta= tus flags to know the status of the LSP. As section 7.2 of RFC 3473 says:=20 "The Admin_Status object is used to notify each node along the path of th= e status of the LSP. " > =3D=3D=3D=3D=3D=3D >=20 > idnits shows >=20 > =3D=3D Unused Reference: 'RFC4783' is defined on line 312, but no expli= cit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC4872' is defined on line 315, but no expli= cit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC4974' is defined on line 320, but no expli= cit > reference was found in the text >=20 > =3D=3D Unused Reference: 'RFC5852' is defined on line 324, but no expli= cit > reference was found in the text >=20 Thanks for catching this. They were referenced in a previous version. Will = clean up this in a new revision.=20 >=20 > In 3.2 you talk about reporting the LB in the RRO on the corresponding Re= sv. > What about the RRO on the Path that is forwarded downstream? My feeling is the RRO on the Path message MAY carry this information to dow= nstream, while this does not impact the signaling procedure of loopback. > --- >=20 > I think that Section 5 should refer to the security considerations sectio= n of > draft-ietf-teas-lsp-attribute-ro to pick up any concerns with the use of = that > mechanism. Agreed. Will add the reference in a new revision.=20 Many thanks, Jie > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jan 6 04:44:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981BE1A3BA4 for ; Tue, 6 Jan 2015 04:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 Ly_QwalwbZnB for ; Tue, 6 Jan 2015 04:44:04 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174EC1ACCEC for ; Tue, 6 Jan 2015 04:44:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t06ChLhq007455; Tue, 6 Jan 2015 12:43:21 GMT Received: from 950129200 (089144228155.atnat0037.highway.a1.net [89.144.228.155]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t06ChKwP007448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 12:43:21 GMT From: "Adrian Farrel" To: "'Dongjie \(Jimmy\)'" , References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> Date: Tue, 6 Jan 2015 12:43:20 -0000 Message-ID: <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+2Nv9mq9ogOojZJmUjHjhxvwWXgI/mPChm8OhWOA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21226.007 X-TM-AS-Result: No--26.041-10.0-31-10 X-imss-scan-details: No--26.041-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F6nykMun0J1wub1BZhxYQ/GfjJOgArMOCbICb95lYQ6Stf8 GfyWFiP3387h4ORMfKpL1DXElKAN205GqmwdJt7CSEQN/D/3cG7omPrNi98UBN14Aqe8EzF8ATy C25wU2NWPq0zC6uXPS3NzkPc1+QKXCCk23kSAVszAJnGRMfFxyfJVuNtKMtYMbM9BQa7AG2nV9x 7gL2l/Msd60RaU/y5A7VH5Qc/tctKtGUuyWCB/KmwbuvhCHs3cgYy8y+HaPlbUnXz3/AeevzxH8 tKF9a4gbo2GQBtiB+z1eYqS1Vs15ja9BTI9OTwhgQy/ei4MrjGAfODDLypXmrFbhhcWxNQOIE9v 7dw1ta4IS5UXqe5IMZGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPI6T/LTDsmJmg= Archived-At: http://mailarchive.ietf.org/arch/msg/teas/_t3N6vZYUJ4hmAdrrEfzwICDUyI Cc: teas@ietf.org Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 12:44:06 -0000 Hi Jie, Thanks for the prompt response. > > However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags TLV is > > not allowed in the HOP Attributes ERO subobject. I think this is for a good > > reason that many (all?) of bits defined so far have no meaning if targeted at a > > specific transit LSR. > > I guess there may be some confusion about this. Section 5.3.1 of draft-ietf-teas- > lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says it is > "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP > Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my > understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP > Attribute subobject". OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have changed a bit. The WG needs to work this through (no need to involve me :-). If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to change. If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change. > > I think you need to describe what happens if a LB instruction is received when > > the LSP is not admin down. Similarly, what happens when an LSP is moved from > > admin down to admin up when a LB instruction is in force. Is there an > > implication that transit nodes need to inspect the Admin Status flags? > > Agree that we can add some description about these cases. > > Since the lock and loopback requests are originated by the ingress node, maybe > we can specify that the ingress node must not send LB instruction before putting > the LSP into admin down state, also must not move the lsp to admin up when the > lsp is in still loopback mode? Saying what must happen is good, and I think you already do that in the document. > For the transit nodes, my understanding is they could inspect the Admin Status > flags to know the status of the LSP. As section 7.2 of RFC 3473 says: > > "The Admin_Status object is used to notify each node along the path of the > status of the LSP. " Good reference. Thanks. So all you need to describe is the error cases. What does a transit node or egress do when the ingress screws up? > > In 3.2 you talk about reporting the LB in the RRO on the corresponding Resv. > > What about the RRO on the Path that is forwarded downstream? > > My feeling is the RRO on the Path message MAY carry this information to > downstream, while this does not impact the signaling procedure of loopback. Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. You need to decide and document. Probably, it is a SHOULD because it is information about the path. Cheers, Adrian From nobody Tue Jan 6 07:10:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4451A1F01 for ; Tue, 6 Jan 2015 01:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 9jGSnr6LOHtB for ; Tue, 6 Jan 2015 01:12:30 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 15A511A1EEE for ; Tue, 6 Jan 2015 01:12:29 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t069CT0a001436 for ; Tue, 6 Jan 2015 18:12:29 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 6310B5F611 for ; Tue, 6 Jan 2015 18:12:29 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 5628A5F591 for ; Tue, 6 Jan 2015 18:12:29 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t069CTfN020477 for ; Tue, 6 Jan 2015 18:12:29 +0900 Message-ID: <54ABA7B3.5030900@lab.ntt.co.jp> Date: Tue, 06 Jan 2015 18:15:31 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: teas@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/teas/vu3B5TdSqYESrFRHbhZYtDR1M0o X-Mailman-Approved-At: Tue, 06 Jan 2015 07:10:40 -0800 Subject: [Teas] Call for Presentation: iPOP 2015 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:12:32 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation 11th International Conference on IP + Optical Network (iPOP 2015) April 20-22, 2015 Okinawa Jichikaikan, Naha Okinawa Japan http://www.pilab.jp/ipop2015/ Important Dates: Submission deadline of one-page abstract: January 16, 2015 Notification of acceptance: February 23, 2015 Submission deadline of final presentation slides: March 13, 2015 Following the successful events of iPOP, the 11th Conference on IP+Optical Network (iPOP 2015) will be held at Okinawa Jichikaikan, Naha Okinawa Japan, April 20-22, 2015. The conference has been provided opportunities for both of the industry and the academia to share their knowledge, new findings, and experiences on the state-of-the-art IP and optical networking technologies for these ten years. The Technical Program Committee for iPOP 2015 is soliciting presentation proposals for this conference. Architecture and protocol designs, experiments/PoCs/field trials, theories/algorithms, implementations, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Control plane (MPLS/GMPLS, OpenFlow, etc) * SDN for packet and optical transport networks * MLN (Multi-Layer Network), MRN (Multi-Region Network) * TE (Traffic Engineering), PCE (Path Computation Element) * Network abstraction/virtualization * Flex-grid, elastic optical networks * Optical networking/switching for cloud services * Data center and WAN orchestration * Carrier Ethernet and MPLS-TP for backhauling * Service function chaining for mobile networks * Security * QoS (Quality of Service)/QoE (Quality of Experience) * Network operation and management * Standardization/interoperability * Open Source Software (OSS) for SDN/NFV * DevOps Submit an extended abstract (400 words, 1 page), including figures and diagrams, speaker’s name, affiliation, and contact information, to the Technical Program Committee: ipop2015-cfp@pilab.jp. Please see http://www.pilab.jp/ipop2015/ for more details. ------------------------------------------------------------------------ -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 From nobody Tue Jan 6 17:25:52 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3CC1A1B66 for ; Tue, 6 Jan 2015 17:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UUcAgO4ZU4mO for ; Tue, 6 Jan 2015 17:25:48 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310931A1B38 for ; Tue, 6 Jan 2015 17:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9603; q=dns/txt; s=iport; t=1420593948; x=1421803548; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6brOyU/sOPJUKxiWTWGFkDAeyXicGpozWds5gDEs3rI=; b=j8/QhvFstiVa9VbHCGtR+Ng2sGGGMqxYbVRjnFmi4vVm/Cr/llJ04M6X gwm5fVtFy4SfMx5yt9gWbvQJpz+nqf8LyLkfinc/F9M1n1zRaF4wJMty1 Hs0oG3kdMuqnAtHdIVI0s5MJRTVuw/LxTL0qE6BSSbcPUnKN4uKrgKpDm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAKyKrFStJV2S/2dsb2JhbABcgwZSWATGPwqFcwKBDxYBAQEBAX2EDAEBAQQBAQE3MQMLDAIEAQgRAwEBAQEeCSIGBgsUCQgBAQQOBYgYAxENvywNg1oBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASNSoFIEAIBTwcGhCMFhSyIeYVAgXWBRIENgmqCNIVWgiKDOSKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,711,1413244800"; d="scan'208";a="385240773" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jan 2015 01:25:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t071PkUs023896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 01:25:47 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.59]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 19:25:46 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6AABXMfIAABlTzgAJ11UUA Date: Wed, 7 Jan 2015 01:25:45 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8C7EEB@eusaamb103.ericsson.se> 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.226.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/3Ch4t1NKrj_5Fzj_Hz2-QK4e6Jc Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:25:51 -0000 Hi Gregory, Thank you for your review comments. Can u please elaborate how does segment protection using ASSOCIATION object solve the highlighted issue ? I am thinking such mechanisms would apply to FRR as well. Thanks, Rakesh On 2014-12-25 2:51 AM, "Gregory Mirsky" wrote: >Dear All, >I think that node protection mode for bidirectional co-routed LSP FRR is >cumbersome and, at best, likely cause out-of-order delivery and more >service disruption (switching reverse direction on R5 from R4 onto R3 >triggered by tunneled RSVP Path message). I believe that extension of RFC >4090 for bidirectional co-routed LSP FRR is viable only for link >protection mode and node protection must be referred to segment >protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >Without such change in the scope of the draft I cannot support its >adoption by the WG. > > Regards, > Greg > >-----Original Message----- >From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >Sent: Wednesday, December 24, 2014 8:50 PM >To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >Cc: TEAS WG >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Working Group, > >I was almost through my review of this document, saw Nobo's review and >found that he had found everything I found and a bit more :). > >With that and with Rakesh's statement that the comments will be addressed >I souppor the adoption of the document as a wg doc. > >/Loa > >On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >> Thank you Nobo for your detailed review comments. >> >> We will address these in the next revision. >> >> Happy holidays. >> >> Thanks, >> Rakesh >> >> >> From: "Nobo Akiya (nobo)" > >> Date: Wednesday, 24 December, 2014 5:45 PM >> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >> " >> > >> > >> Cc: TEAS WG > >> Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> Resent-From: > > >> Resent-To: "frederic.jounay@orange.ch >> " > >, "Lizhong com>" >> >, >> >, >>"=3DSMTP:mtaillon@cisco. com" >> >, Rakesh Gandhi >> >, > >, Zafar Ali > > >> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >> >> Hi Authors, >> >> Happy Holidays! >> >> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of >> its WG adoption poll), and had some questions/comments. Please find >>them below. >> >> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may >> be easier to understand if "list" is used. >> >> [OLD] >> >> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >> object >> >> prior to adding the node's IP address in the node-ID subobject. A >> >> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also >> adding a >> >> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >> subobject >> >> without also adding an IPv4 or IPv6 subobject. >> >> [NEW] >> >> When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >> >> object: >> >> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >> node-ID >> >> subobject describing the node's IP address. >> >> o The Node-ID subobject MUST also be added. >> >> o The IPv4 or IPv6 subobject MUST also be added. >> >> 2) Section 4.4.1 - First sentence of the third paragraph was quite >> difficult to read/understand. Perhaps adding some commas and >> quotations may improve its readability. >> >> [OLD] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject whose bypass tunnel and the node-ID subobject when used >> as >> >> a bypass tunnel source terminates locally assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and forwards >> >> the RSVP Path message downstream. >> >> [NEW] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject, whose bypass tunnel and the node-ID subobject when used >> as >> >> a "bypass tunnel source" terminates locally, assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and forwards >> >> the RSVP Path message downstream. >> >> 3) Section 4.4.1 - I have a slight concern regarding below statement. >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >> does >> >> not assign a bypass tunnel in the reverse direction. This allows >> the >> >> downstream PLR to always initiate the bypass assignment and >> upstream >> >> PLR to simply reflect the bypass assignment. >> >> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >> >> subobjects from multiple downstream PLRs, the decision of >> selecting a >> >> bypass tunnel in the reverse direction can be based on local >> policy, >> >> for example, prefer link protection versus node protection bypass >> >> tunnel, or prefer the most upstream versus least upstream node >> >> protection bypass tunnel. >> >> [snip] >> >> When LSRs within a bidirectional LSP employ different policies, as >> described above, then we can result in pockets where there are no >> protections. >> >> For example: >> >> Node A uses node protection. >> >> Node B and C use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +-+ >> >> The result of above is that, in the reverse direction, there will not >> be any protection between nodes B and A. >> >> Another example: >> >> Node A and C use node protection. >> >> Node B use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +----------+ >> >> The result of above is that, in the reverse direction, there will not >> be any protection between nodes B and A. >> >> In both cases, if there is a breakage of the link connecting nodes A >> and B, then node C receives the RSVP PATH message. If node C follows >> procedures described in Section 6.2, then it will not find a matching >> bypass tunnel. >> >> If I'm off track, then I apologize for the noise. If above is indeed a >> problem, then this limitation should at least be described in the >> document, followed by a recommendation of all LSRs within a >> bidirectional tunnel employing the same policy. >> >> It may be possible to (be brave and) address this but it will require >> more procedures. I'll leave the decision and further investigation to >> the authors. >> >> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >> does >> >> not assign a bypass tunnel in the reverse direction. This allows >> the >> >> downstream PLR to always initiate the bypass assignment and >> upstream >> >> PLR to simply reflect the bypass assignment. >> >> [snip] >> >> I'm guessing that there should be a SHOULD ... >> >> 5) Section 6.2 - "If" and "If not" in below text do not correspond to >> each other (thus a bit confusing). >> >> [snip] >> >> - If found, checks whether the primary LSP traffic and >> signaling >> >> are already rerouted over the found bypass tunnel. If not, >> PRR >> >> R5 activates FRR reroute procedures to direct traffic and >> >> RSVP Resv over the found bypass tunnel T2 in the >> >> reverse direction. >> >> [snip] >> >> If we write above with a psuedocode, then it will be: >> >> if (bypass tunnel found) { // "If found" is this line >> >> check if already rerouted >> >> if (not already rerouted) { // "If not" is this line >> >> active FRR reroute >> >> } >> >> } >> >> It might make the texts easier to read/understand if you can rephrase >> it a bit? >> >> Thanks! >> >> -Nobo >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jan 6 18:18:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09A71A88D6 for ; Tue, 6 Jan 2015 18:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 MrdtV9dJvDnX for ; Tue, 6 Jan 2015 18:18:45 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512E71A88D5 for ; Tue, 6 Jan 2015 18:18:45 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-03-54ac45b7a54f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7B.10.03307.7B54CA45; Tue, 6 Jan 2015 21:29:44 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 21:18:43 -0500 From: Gregory Mirsky To: "Rakesh Gandhi (rgandhi)" Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AQHQH/5YrpjNjKgiDky+ptAkRBgJ1Zyf6ZMQgBRb+YD//7QPAA== Date: Wed, 7 Jan 2015 02:18:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8CBBCF@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B8C7EEB@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLonVneH65oQg0NzBC2OT5/AYrHi9DNm i4lHPrBYbF1ynMlialMHm0Xrjx0sFp9O/GSyeL3jK7sDh8eU3xtZPXbOusvusWTJTyaPmTvn MHnc2KoYwBrFZZOSmpNZllqkb5fAlfH+4y6mgqNhFS9f7WVvYNzv3MXIySEhYCLxvOcEO4Qt JnHh3nq2LkYuDiGBI4wSZ59PZIVwljFKrLz7hw2kik3ASOLFxh6wDhEBQ4nD3avBipgFljJJ NLb0MIIkhAWCJc48eQ+U4AAqCpF4dc0Pot5JYs3f+2BzWARUJNrn7gIr5xXwlTjx6TsriC0k UCRx/vlvsPmcAvoSB/YsArMZga77fmoNE4jNLCAucevJfCaIqwUkluw5zwxhi0q8fPyPFcJW kpi09BwrRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKU FqeW5aYbGWxiBMbfMQk23R2Me15aHmIU4GBU4uHd4L86RIg1say4MvcQozQHi5I476zaecFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGHuYRfbIaNZ0bt6yrFUryCO6Ylon19cfR1cGMBf0 6t3X133gLCz40+D/uStyB2drFC29a7u2IXrWa9bdSi5cj15N3Kqzd90OPsH7vTOnhT/7I9OV eirK0XPfjOLzz3cvzPjR8EY5kDPi+SQ7pgVaTuUdM+4ePXVhf9ummPSKlhvJfEEX782xPa3E UpyRaKjFXFScCAARTEeyoAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/teas/tlmL0L-X5uWaIdoE49wjAUFBe0s Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 02:18:49 -0000 Hi Rakesh, thank you for your interest in my comments. I can note that during work on MPLS-TP we, as union of MPLS and CCAMP WGs, = left question of RSVP FRR applicability undocumented. Perhaps we can find m= ailing list discussions where some of us agreed that local protection of un= i-directional and bi-directional associated LSPs in MPLS-TP can follow RFC = 4090 but question of local protection of bi-directional co-routed LSPs requ= ires further discussion. And there already were references to use ASSOCIATI= ON object to support segment protection if node protection desired. That wo= uld allow monitoring of both working and protecting paths and switchover co= ordination by using RFC 6378. Of course, proposed mechanism is workable as control plane restoration mech= anism but I'm not convinced that is what should be standardized as local pr= otection mechanism. Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]=20 Sent: Tuesday, January 06, 2015 5:26 PM To: Gregory Mirsky Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); Zaf= ar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Gregory, Thank you for your review comments. Can u please elaborate how does segment protection using ASSOCIATION object= solve the highlighted issue ? I am thinking such mechanisms would apply t= o FRR as well. Thanks, Rakesh On 2014-12-25 2:51 AM, "Gregory Mirsky" wrote: >Dear All, >I think that node protection mode for bidirectional co-routed LSP FRR=20 >is cumbersome and, at best, likely cause out-of-order delivery and more=20 >service disruption (switching reverse direction on R5 from R4 onto R3=20 >triggered by tunneled RSVP Path message). I believe that extension of=20 >RFC >4090 for bidirectional co-routed LSP FRR is viable only for link=20 >protection mode and node protection must be referred to segment=20 >protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >Without such change in the scope of the draft I cannot support its=20 >adoption by the WG. > > Regards, > Greg > >-----Original Message----- >From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >Sent: Wednesday, December 24, 2014 8:50 PM >To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);=20 >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >Cc: TEAS WG >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Working Group, > >I was almost through my review of this document, saw Nobo's review and=20 >found that he had found everything I found and a bit more :). > >With that and with Rakesh's statement that the comments will be=20 >addressed I souppor the adoption of the document as a wg doc. > >/Loa > >On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >> Thank you Nobo for your detailed review comments. >> >> We will address these in the next revision. >> >> Happy holidays. >> >> Thanks, >> Rakesh >> >> >> From: "Nobo Akiya (nobo)" > >> Date: Wednesday, 24 December, 2014 5:45 PM >> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >> " >> > > > >> > >> Cc: TEAS WG > >> Subject: Mail regarding=20 >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> Resent-From: > > >> Resent-To: "frederic.jounay@orange.ch =20 >>" >>, "Lizhong com>" >> >, =20 >>>, >>"=3DSMTP:mtaillon@cisco. com" >> >, Rakesh Gandhi =20 >>>, >>, Zafar Ali >> >> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >> >> Hi Authors, >> >> Happy Holidays! >> >> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of =20 >>its WG adoption poll), and had some questions/comments. Please find=20 >>them below. >> >> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may=20 >> be easier to understand if "list" is used. >> >> [OLD] >> >> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE=20 >> object >> >> prior to adding the node's IP address in the node-ID subobject. =20 >> A >> >> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also=20 >> adding a >> >> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT=20 >> subobject >> >> without also adding an IPv4 or IPv6 subobject. >> >> [NEW] >> >> When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >> >> object: >> >> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the=20 >> node-ID >> >> subobject describing the node's IP address. >> >> o The Node-ID subobject MUST also be added. >> >> o The IPv4 or IPv6 subobject MUST also be added. >> >> 2) Section 4.4.1 - First sentence of the third paragraph was quite=20 >> difficult to read/understand. Perhaps adding some commas and=20 >> quotations may improve its readability. >> >> [OLD] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject whose bypass tunnel and the node-ID subobject when used=20 >> as >> >> a bypass tunnel source terminates locally assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and=20 >> forwards >> >> the RSVP Path message downstream. >> >> [NEW] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject, whose bypass tunnel and the node-ID subobject when=20 >> used as >> >> a "bypass tunnel source" terminates locally, assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and=20 >> forwards >> >> the RSVP Path message downstream. >> >> 3) Section 4.4.1 - I have a slight concern regarding below statement. >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR=20 >> does >> >> not assign a bypass tunnel in the reverse direction. This allows=20 >> the >> >> downstream PLR to always initiate the bypass assignment and=20 >> upstream >> >> PLR to simply reflect the bypass assignment. >> >> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >> >> subobjects from multiple downstream PLRs, the decision of=20 >> selecting a >> >> bypass tunnel in the reverse direction can be based on local=20 >> policy, >> >> for example, prefer link protection versus node protection bypass >> >> tunnel, or prefer the most upstream versus least upstream node >> >> protection bypass tunnel. >> >> [snip] >> >> When LSRs within a bidirectional LSP employ different policies, as=20 >> described above, then we can result in pockets where there are no=20 >> protections. >> >> For example: >> >> Node A uses node protection. >> >> Node B and C use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +-+ >> >> The result of above is that, in the reverse direction, there will not=20 >> be any protection between nodes B and A. >> >> Another example: >> >> Node A and C use node protection. >> >> Node B use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +----------+ >> >> The result of above is that, in the reverse direction, there will not=20 >> be any protection between nodes B and A. >> >> In both cases, if there is a breakage of the link connecting nodes A=20 >> and B, then node C receives the RSVP PATH message. If node C follows=20 >> procedures described in Section 6.2, then it will not find a matching=20 >> bypass tunnel. >> >> If I'm off track, then I apologize for the noise. If above is indeed=20 >> a problem, then this limitation should at least be described in the=20 >> document, followed by a recommendation of all LSRs within a=20 >> bidirectional tunnel employing the same policy. >> >> It may be possible to (be brave and) address this but it will require=20 >> more procedures. I'll leave the decision and further investigation to=20 >> the authors. >> >> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR=20 >> does >> >> not assign a bypass tunnel in the reverse direction. This allows=20 >> the >> >> downstream PLR to always initiate the bypass assignment and=20 >> upstream >> >> PLR to simply reflect the bypass assignment. >> >> [snip] >> >> I'm guessing that there should be a SHOULD ... >> >> 5) Section 6.2 - "If" and "If not" in below text do not correspond to=20 >> each other (thus a bit confusing). >> >> [snip] >> >> - If found, checks whether the primary LSP traffic and=20 >> signaling >> >> are already rerouted over the found bypass tunnel. If not,=20 >> PRR >> >> R5 activates FRR reroute procedures to direct traffic and >> >> RSVP Resv over the found bypass tunnel T2 in the >> >> reverse direction. >> >> [snip] >> >> If we write above with a psuedocode, then it will be: >> >> if (bypass tunnel found) { // "If found" is this line >> >> check if already rerouted >> >> if (not already rerouted) { // "If not" is this line >> >> active FRR reroute >> >> } >> >> } >> >> It might make the texts easier to read/understand if you can=20 >> rephrase it a bit? >> >> Thanks! >> >> -Nobo >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Jan 6 18:45:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B338F1A890D for ; Tue, 6 Jan 2015 18:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jqx3YyjRie7x for ; Tue, 6 Jan 2015 18:45:23 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195BE1A8900 for ; Tue, 6 Jan 2015 18:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11751; q=dns/txt; s=iport; t=1420598723; x=1421808323; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X6/5oWBV/p4okFJOdub15Q5IWuD6c5SIZjtiLhR6o0I=; b=E3N1+quGKeivPCr7hyS5P/gT7BsUYFZbvVB0a/umEPzkhY4QW4bknBAF pgqU8rKiIVyGAplyUw6TF8P3AJYk+/fwrZMEnE87wEYpvXymkmV6OGoxw 9P2PKCYj9SbKF8dy9ZbJrGnOUc+DuJch1dPRcjVQOp5LhYYk8erwkzFWj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAEmdrFStJV2Q/2dsb2JhbABcgwZSWATGSAqFcwKBEBYBAQEBAX2EDAEBAQQBAQE3MQMLDAIEAQgRAwEBAQEeCSIGBgsUCQgCBA4FiBgDEQ2/Pw2DWgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI1KgUgQAgFPBwaEIwWFLIh5hUCBdYFEgQ2CaoI0hVaCIoM5IoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,711,1413244800"; d="scan'208";a="110934278" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 07 Jan 2015 02:45:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t072jKZB013170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 02:45:20 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.59]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 20:45:20 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6AABXMfIAABlTzgAJ11UUAAAxUN4D//7OagA== Date: Wed, 7 Jan 2015 02:45:20 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8CBBCF@eusaamb103.ericsson.se> 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.226.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/teas/Mr54vEpXzXhn2w6cSW7-UagR27Q Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 02:45:27 -0000 Hi Gregory, Thank you for the context. Good stuff. May be we could state in the draft something along the line of: "PSC (RFC6378) is applicable to FRR (RFC4090) for local protection switchover in both directions in order to minimize traffic disruptions. In the absence of such mechanism, control plane restoration proposed is required in order to avoid soft state time out". Would that work? thanks, Rakesh On 2015-01-06 9:18 PM, "Gregory Mirsky" wrote: >Hi Rakesh, >thank you for your interest in my comments. >I can note that during work on MPLS-TP we, as union of MPLS and CCAMP >WGs, left question of RSVP FRR applicability undocumented. Perhaps we can >find mailing list discussions where some of us agreed that local >protection of uni-directional and bi-directional associated LSPs in >MPLS-TP can follow RFC 4090 but question of local protection of >bi-directional co-routed LSPs requires further discussion. And there >already were references to use ASSOCIATION object to support segment >protection if node protection desired. That would allow monitoring of >both working and protecting paths and switchover coordination by using >RFC 6378. >Of course, proposed mechanism is workable as control plane restoration >mechanism but I'm not convinced that is what should be standardized as >local protection mechanism. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Tuesday, January 06, 2015 5:26 PM >To: Gregory Mirsky >Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); >Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Hi Gregory, > >Thank you for your review comments. > >Can u please elaborate how does segment protection using ASSOCIATION >object solve the highlighted issue ? I am thinking such mechanisms would >apply to FRR as well. > >Thanks, >Rakesh > > >On 2014-12-25 2:51 AM, "Gregory Mirsky" >wrote: > >>Dear All, >>I think that node protection mode for bidirectional co-routed LSP FRR >>is cumbersome and, at best, likely cause out-of-order delivery and more >>service disruption (switching reverse direction on R5 from R4 onto R3 >>triggered by tunneled RSVP Path message). I believe that extension of >>RFC >>4090 for bidirectional co-routed LSP FRR is viable only for link >>protection mode and node protection must be referred to segment >>protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >>Without such change in the scope of the draft I cannot support its >>adoption by the WG. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >>Sent: Wednesday, December 24, 2014 8:50 PM >>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>Cc: TEAS WG >>Subject: Re: [Teas] Mail regarding >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> >>Working Group, >> >>I was almost through my review of this document, saw Nobo's review and >>found that he had found everything I found and a bit more :). >> >>With that and with Rakesh's statement that the comments will be >>addressed I souppor the adoption of the document as a wg doc. >> >>/Loa >> >>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >>> Thank you Nobo for your detailed review comments. >>> >>> We will address these in the next revision. >>> >>> Happy holidays. >>> >>> Thanks, >>> Rakesh >>> >>> >>> From: "Nobo Akiya (nobo)" > >>> Date: Wednesday, 24 December, 2014 5:45 PM >>> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>> " >>> >> >> > >>> > >>> Cc: TEAS WG > >>> Subject: Mail regarding >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>> Resent-From: >> > >>> Resent-To: "frederic.jounay@orange.ch >>>" >>>, "Lizhong com>" >>> >, >>>>, >>>"=3DSMTP:mtaillon@cisco. com" >>> >, Rakesh Gandhi >>>>, >>>, Zafar Ali >>> >>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >>> >>> Hi Authors, >>> >>> Happy Holidays! >>> >>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of >>>its WG adoption poll), and had some questions/comments. Please find >>>them below. >>> >>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may >>> be easier to understand if "list" is used. >>> >>> [OLD] >>> >>> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >>> object >>> >>> prior to adding the node's IP address in the node-ID subobject. >>> A >>> >>> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also >>> adding a >>> >>> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >>> subobject >>> >>> without also adding an IPv4 or IPv6 subobject. >>> >>> [NEW] >>> >>> When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >>> >>> object: >>> >>> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >>> node-ID >>> >>> subobject describing the node's IP address. >>> >>> o The Node-ID subobject MUST also be added. >>> >>> o The IPv4 or IPv6 subobject MUST also be added. >>> >>> 2) Section 4.4.1 - First sentence of the third paragraph was quite >>> difficult to read/understand. Perhaps adding some commas and >>> quotations may improve its readability. >>> >>> [OLD] >>> >>> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >>> >>> subobject whose bypass tunnel and the node-ID subobject when used >>> as >>> >>> a bypass tunnel source terminates locally assigns the matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> [NEW] >>> >>> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >>> >>> subobject, whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a "bypass tunnel source" terminates locally, assigns the matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> 3) Section 4.4.1 - I have a slight concern regarding below statement. >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This allows >>> the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >>> >>> subobjects from multiple downstream PLRs, the decision of >>> selecting a >>> >>> bypass tunnel in the reverse direction can be based on local >>> policy, >>> >>> for example, prefer link protection versus node protection bypass >>> >>> tunnel, or prefer the most upstream versus least upstream node >>> >>> protection bypass tunnel. >>> >>> [snip] >>> >>> When LSRs within a bidirectional LSP employ different policies, as >>> described above, then we can result in pockets where there are no >>> protections. >>> >>> For example: >>> >>> Node A uses node protection. >>> >>> Node B and C use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +-+ >>> >>> The result of above is that, in the reverse direction, there will not >>> be any protection between nodes B and A. >>> >>> Another example: >>> >>> Node A and C use node protection. >>> >>> Node B use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +----------+ >>> >>> The result of above is that, in the reverse direction, there will not >>> be any protection between nodes B and A. >>> >>> In both cases, if there is a breakage of the link connecting nodes A >>> and B, then node C receives the RSVP PATH message. If node C follows >>> procedures described in Section 6.2, then it will not find a matching >>> bypass tunnel. >>> >>> If I'm off track, then I apologize for the noise. If above is indeed >>> a problem, then this limitation should at least be described in the >>> document, followed by a recommendation of all LSRs within a >>> bidirectional tunnel employing the same policy. >>> >>> It may be possible to (be brave and) address this but it will require >>> more procedures. I'll leave the decision and further investigation to >>> the authors. >>> >>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This allows >>> the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> [snip] >>> >>> I'm guessing that there should be a SHOULD ... >>> >>> 5) Section 6.2 - "If" and "If not" in below text do not correspond to >>> each other (thus a bit confusing). >>> >>> [snip] >>> >>> - If found, checks whether the primary LSP traffic and >>> signaling >>> >>> are already rerouted over the found bypass tunnel. If not, >>> PRR >>> >>> R5 activates FRR reroute procedures to direct traffic and >>> >>> RSVP Resv over the found bypass tunnel T2 in the >>> >>> reverse direction. >>> >>> [snip] >>> >>> If we write above with a psuedocode, then it will be: >>> >>> if (bypass tunnel found) { // "If found" is this line >>> >>> check if already rerouted >>> >>> if (not already rerouted) { // "If not" is this line >>> >>> active FRR reroute >>> >>> } >>> >>> } >>> >>> It might make the texts easier to read/understand if you can >>> rephrase it a bit? >>> >>> Thanks! >>> >>> -Nobo >>> >>> >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>Teas mailing list >>Teas@ietf.org >>https://www.ietf.org/mailman/listinfo/teas > From nobody Wed Jan 7 08:59:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4AE1A0055 for ; Wed, 7 Jan 2015 08:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] autolearn=no 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 Y3B_ledPLb3x for ; Wed, 7 Jan 2015 08:59:13 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EFE1A0012 for ; Wed, 7 Jan 2015 08:59:13 -0800 (PST) Received: from localhost ([::1]:59079) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8twt-0007Yr-Vs; Wed, 07 Jan 2015 19:59:12 +0300 Message-ID: <54AD65DC.9040005@labn.net> Date: Wed, 07 Jan 2015 11:59:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Dongjie (Jimmy)'" , teas@ietf.org References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> In-Reply-To: <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/teas/Ehl9mNmuj4UMYuTeCl3uMTn3rv4 Cc: draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:59:15 -0000 [resend] Adrian (all), On 1/6/2015 7:43 AM, Adrian Farrel wrote: > Hi Jie, > > Thanks for the prompt response. Restoring some overly aggressive culling: >>> You want to use a bit in the Attribute Flags TLV to indicate Loopback >>> and propose including that TLV in the HOP Attributes ERO subobject as >>> defined in draft-ietf-ccamp-lsp-attribute-ro. >>> However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags > TLV is >>> not allowed in the HOP Attributes ERO subobject. I think this is for a good >>> reason that many (all?) of bits defined so far have no meaning if targeted > at a >>> specific transit LSR. >> I guess there may be some confusion about this. Section 5.3.1 of > draft-ietf-teas- >> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says > it is >> "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP >> Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my >> understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP >> Attribute subobject". > OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have > changed a bit. > > The WG needs to work this through (no need to involve me :-). > If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to > change. > If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change. I this document is correct, and think you've identified a few issues with draft-ietf-teas-lsp-attribute-ro (which has also been submitted for publication) and I'll start a new thread on these. >>> I think you need to describe what happens if a LB instruction is received > when >>> the LSP is not admin down. Similarly, what happens when an LSP is moved from >>> admin down to admin up when a LB instruction is in force. Is there an >>> implication that transit nodes need to inspect the Admin Status flags? >> Agree that we can add some description about these cases. >> >> Since the lock and loopback requests are originated by the ingress node, maybe >> we can specify that the ingress node must not send LB instruction before > putting >> the LSP into admin down state, also must not move the lsp to admin up when the >> lsp is in still loopback mode? > Saying what must happen is good, and I think you already do that in the > document. > >> For the transit nodes, my understanding is they could inspect the Admin Status >> flags to know the status of the LSP. As section 7.2 of RFC 3473 says: >> >> "The Admin_Status object is used to notify each node along the path of the >> status of the LSP. " > Good reference. Thanks. > > So all you need to describe is the error cases. What does a transit node or > egress do when the ingress screws up? So you are asking for a new sentence in paragraph 3 of section 3.2. Perhaps something like: OLD On receipt of this Path message, the target LSR of the loopback request SHOULD try to put the LSP into loopback mode. If the node puts the LSP into loopback mode successfully, it MUST set the NEW On receipt of this Path message, the target node of the loopback request MUST check if the LSP is in lock mode by verifying that the Administratively down (A) bit is set in the ADMIN_STATUS object. If the bit is not set, the loopback request MUST be ignored. If the bit is set the node SHOULD try to put the LSP into loopback mode. If the node puts the LSP into loopback mode successfully, it MUST set the > >>> In 3.2 you talk about reporting the LB in the RRO on the corresponding Resv. >>> What about the RRO on the Path that is forwarded downstream? >> My feeling is the RRO on the Path message MAY carry this information to >> downstream, while this does not impact the signaling procedure of loopback. > Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. You need > to decide and document. How about: OLD If the node puts the LSP into loopback mode successfully, it MUST set the Loopback (B) bit in the Record Route Object (RRO) Attribute subobject [RFC5420] and push this subobject onto the RRO object in the corresponding Resv message. NEW If the node puts the LSP into loopback mode successfully, it MUST set the Loopback (B) bit if it adds, per [RFC5420], an Attribute subobject to the RECORD_ROUTE object of a Path or Resv message. > Probably, it is a SHOULD because it is information about the path. > > Cheers, > Adrian > One additional comment of my own. For consistency, only LSR or node should be used -- they are currently used about equally. I suggest replacing "LSR" with "node" . (Sorry, I thought we did this for this document already, but clearly I missed this due too much eggnog.) Thanks, Lou From nobody Wed Jan 7 09:00:18 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE471A004B for ; Wed, 7 Jan 2015 09:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] autolearn=no 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 D6lHbbL9tao7 for ; Wed, 7 Jan 2015 09:00:14 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1681A00AD for ; Wed, 7 Jan 2015 09:00:12 -0800 (PST) Received: from localhost ([::1]:59444) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8txm-0007gC-1o; Wed, 07 Jan 2015 20:00:07 +0300 Message-ID: <54AD6610.5010205@labn.net> Date: Wed, 07 Jan 2015 12:00:00 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, teas@ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AC2352.6010900@labn.net> In-Reply-To: <54AC2352.6010900@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/teas/cEAOR9g9VlMtbkReavZ4clqAVHo Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 17:00:16 -0000 [resend] All, I believe Adrian has identified a few issues with draft-ietf-teas-lsp-attribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for context. In particular: 1) In the IANA section, the document states that Attribute Flags cannot be carried in a LSP Hop Attributes subobject. It looks like this was a cut&paste bug introduced in rev 01 when translating the expanded directions into table form. The old -00 text in section 5.3.1 said: o Allowed on LSP attribute ERO subobject so the following change should be made. OLD: 1 Attribute Flags Yes Yes No [RFC5420] NEW 1 Attribute Flags Yes Yes Yes [RFC5420] 2) Adrian points out that many existing flags really don't make sense in in the LSP attribute ERO subobject and I think this should be documented. To do this fully, I think we can either preclude usage of existing flags or allow for specific flags (I could see allowing it for MIP, SRLG collection, but am okay either way). Either way there should be an explicit statement on this, as well as a new column in the IANA table (with a new IANA section describing this change). For the explicit statement, how about adding the following to the end of section 2.2: The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject. Flags set in the an Attribute Flags TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be interpreted in the context of the received ERO. Only a subset of defined flags are defined as valid for use in Attribute Flags TLV carried in a ERO Hop Attributes Subobject. Invalid flags SHALL be silently ignored. Unknown flags SHOULD trigger the generation of a PathErr with Error Code "Unknown Attributes Bit" as defined in [RFC5420] Section 5.2. And 4.3. Existing Attribute Flags IANA manages the "Attribute Flags" registry as part of the "RSVP-TE PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- parameters.xml. A new column in the registry is introduced by this document. This column indicates if the flag is permitted to be used in a Attribute Flags TLV carried in the ERO Hop Attributes Subobject. The column uses the heading "ERO" and the registery is to be updated as follows: Bit Name Attribute Attribute RRO ERO Reference FlagsPath FlagsResv 0 End-to-end re-routing Yes No No No [RFC4920] [RFC5420] 1 Boundary re-routing Yes No No No [RFC4920] [RFC5420] 2 Segment-based re-routing Yes No No No [RFC4920] [RFC5420] 3 LSP Integrity Required Yes No No No [RFC4875] 4 Contiguous LSP Yes No Yes No [RFC5151] 5 LSP stitching desired Yes No Yes No [RFC5150] 6 Pre-Planned LSP Flag Yes No No No [RFC6001] 7 Non-PHP behavior flag Yes No Yes No [RFC6511] 8 OOB mapping flag Yes No Yes No [RFC6511] 9 Entropy Label Capability Yes Yes No No [RFC6790] 10 OAM MEP entities desired Yes Yes Yes No [RFC7260] 11 OAM MIP entities desired Yes Yes Yes No [RFC7260] 12 SRLG collection Flag Yes Yes Yes No [draft-ietf- (TEMPORARY - registered ccamp-rsvp- 2014-09-11, expires te-srlg- 2015-09-11) collect] New allocation requests to this registry shall indicate the value to be used in the ERO column. 3) the discussion also caught one naming inconsistency: s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject I think that's it. Comments? Lou On 1/6/2015 1:02 PM, Lou Berger wrote: > Adrian (all) > > On 1/6/2015 7:43 AM, Adrian Farrel wrote: > ... >>> You want to use a bit in the Attribute Flags TLV to indicate Loopback >>> and propose including that TLV in the HOP Attributes ERO subobject as >>> defined in draft-ietf-ccamp-lsp-attribute-ro. >>>> However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags >> TLV is >>>> not allowed in the HOP Attributes ERO subobject. I think this is for a good >>>> reason that many (all?) of bits defined so far have no meaning if targeted >> at a >>>> specific transit LSR. >>> I guess there may be some confusion about this. Section 5.3.1 of >> draft-ietf-teas- >>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says >> it is >>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP >>> Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my >>> understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP >>> Attribute subobject". >> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have >> changed a bit. >> >> The WG needs to work this through (no need to involve me :-). >> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to >> change. >> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change. > I this document is correct, and think you've identified a few issues > with draft-ietf-teas-lsp-attribute-ro (which has also been submitted for > publication) and I'll start a new thread on these. > From nobody Wed Jan 7 13:53:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD811A6FDB for ; Wed, 7 Jan 2015 13:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 mFm3__YXZbT2 for ; Wed, 7 Jan 2015 13:53:08 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53221A1B93 for ; Wed, 7 Jan 2015 13:53:07 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 0caada45.0.1335361.00-2002.3765485.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 07 Jan 2015 21:53:07 +0000 (UTC) X-MXL-Hash: 54adaac308b9c6c5-0f01f5597815ed68329e2f971784cf7567f4a7fa Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t07Lr4HZ021652 for ; Wed, 7 Jan 2015 16:53:04 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t07LqwCP021610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Jan 2015 16:52:59 -0500 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Wed, 7 Jan 2015 21:52:43 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.4]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 16:52:43 -0500 From: "BRUNGARD, DEBORAH A" To: "teas@ietf.org" Thread-Topic: Publication requested for draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdAqxDbkXu5qCxaIScGHOBjF/JaElw== Date: Wed, 7 Jan 2015 21:52:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.66.208] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C816731843MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NJ9iDTGg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=cVV6W6eTNEgA:10 a=zisXeA3k5MgA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YNv0rlydsVwA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=wfD9Ddt7GEflTOZP8PMA:9 a=CjuIK1q_8ugA:10 a=n0gXrjH] X-AnalysisOut: [fUDoA:10 a=f-0zr-bLRiEA:10 a=1dHumoC4ti8A:10 a=_W_S_7VecoQ] X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=ZlEmVHaO8y53qlPW:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/teas/0-rBPcIruj_zPE41lmT1PHAeLf8 Subject: [Teas] Publication requested for draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:53:10 -0000 --_000_F64C10EAA68C8044B33656FA214632C816731843MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The publication request for this has been submitted via datatracker. If int= erested, it is here: http://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associat= ed-lsp/ Deborah --_000_F64C10EAA68C8044B33656FA214632C816731843MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
The publication request for this has been submitted via datatracker. I= f interested, it is here:
http://datatracker.ietf.or= g/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp/
 
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C816731843MISOUT7MSGUSRDE_-- From nobody Wed Jan 7 18:26:27 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC11A1B3E for ; Wed, 7 Jan 2015 18:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aurnXdo7FAV5 for ; Wed, 7 Jan 2015 18:26:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7803E1A0151 for ; Wed, 7 Jan 2015 18:26:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNS64167; Thu, 08 Jan 2015 02:26:19 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 8 Jan 2015 02:26:18 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 8 Jan 2015 10:26:12 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Thread-Index: AdAnYhVCF4WqjWyETKKYnD4PKpwBSgB8CmtQAAZDKQAAOzmiAAAkdnvA Date: Thu, 8 Jan 2015 02:26:12 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F4CC8@nkgeml512-mbx.china.huawei.com> References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AD65DC.9040005@labn.net> In-Reply-To: <54AD65DC.9040005@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/teas/JAimcO2vNATWREi7SLGSAYOoJnI Cc: "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 02:26:25 -0000 Hi Lou, Adrian,=20 Thanks a lot for your suggestions. We will revise the document following yo= ur guidance and submit a new revision soon.=20 Best regards, Jie > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, January 08, 2015 12:59 AM > To: adrian@olddog.co.uk; Dongjie (Jimmy); teas@ietf.org > Cc: draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org > Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb >=20 > [resend] >=20 > Adrian (all), >=20 > On 1/6/2015 7:43 AM, Adrian Farrel wrote: > > Hi Jie, > > > > Thanks for the prompt response. > Restoring some overly aggressive culling: >=20 > >>> You want to use a bit in the Attribute Flags TLV to indicate > >>> Loopback and propose including that TLV in the HOP Attributes ERO > >>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro. >=20 > >>> However, draft-ietf-teas-lsp-attribute-ro defines that the > >>> Attributes Flags > > TLV is > >>> not allowed in the HOP Attributes ERO subobject. I think this is for > >>> a good reason that many (all?) of bits defined so far have no > >>> meaning if targeted > > at a > >>> specific transit LSR. > >> I guess there may be some confusion about this. Section 5.3.1 of > > draft-ietf-teas- > >> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, > >> which says > > it is > >> "Allowed on LSP attribute ERO subobject". And in section 5.1, the > >> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute > >> Subobject", thus my understanding is that the "Attributes Flags TLV" > >> is allowed in the "ERO HOP Attribute subobject". > > OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to > > have changed a bit. > > > > The WG needs to work this through (no need to involve me :-). > > If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs > > to change. > > If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to = change. >=20 > I this document is correct, and think you've identified a few issues with > draft-ietf-teas-lsp-attribute-ro (which has also been submitted for > publication) and I'll start a new thread on these. >=20 > >>> I think you need to describe what happens if a LB instruction is > >>> received > > when > >>> the LSP is not admin down. Similarly, what happens when an LSP is > >>> moved from admin down to admin up when a LB instruction is in force. > >>> Is there an implication that transit nodes need to inspect the Admin = Status > flags? > >> Agree that we can add some description about these cases. > >> > >> Since the lock and loopback requests are originated by the ingress > >> node, maybe we can specify that the ingress node must not send LB > >> instruction before > > putting > >> the LSP into admin down state, also must not move the lsp to admin up > >> when the lsp is in still loopback mode? > > Saying what must happen is good, and I think you already do that in > > the document. > > > >> For the transit nodes, my understanding is they could inspect the > >> Admin Status flags to know the status of the LSP. As section 7.2 of RF= C 3473 > says: > >> > >> "The Admin_Status object is used to notify each node along the path > >> of the status of the LSP. " > > Good reference. Thanks. > > > > So all you need to describe is the error cases. What does a transit > > node or egress do when the ingress screws up? > So you are asking for a new sentence in paragraph 3 of section 3.2. > Perhaps something like: > OLD > On receipt of this Path message, the target LSR of the loopback > request SHOULD try to put the LSP into loopback mode. If the node > puts the LSP into loopback mode successfully, it MUST set the NEW > On receipt of this Path message, the target node of the loopback > request MUST check if the LSP is in lock mode by verifying that the > Administratively down (A) bit is set in the ADMIN_STATUS object. > If the bit is not set, the loopback request MUST be ignored. If the > bit is set the node > SHOULD try to put the LSP into loopback mode. If the node > puts the LSP into loopback mode successfully, it MUST set the >=20 > > > >>> In 3.2 you talk about reporting the LB in the RRO on the correspondin= g > Resv. > >>> What about the RRO on the Path that is forwarded downstream? > >> My feeling is the RRO on the Path message MAY carry this information > >> to downstream, while this does not impact the signaling procedure of > loopback. > > Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. > > You need to decide and document. >=20 > How about: > OLD > If the node > puts the LSP into loopback mode successfully, it MUST set the > Loopback (B) bit in the Record Route Object (RRO) Attribute subobject > [RFC5420] and push this subobject onto the RRO object in the > corresponding Resv message. > NEW > If the node > puts the LSP into loopback mode successfully, it MUST set the > Loopback (B) bit if it adds, per [RFC5420], an Attribute subobject > to the RECORD_ROUTE object of a Path or Resv message. >=20 >=20 > > Probably, it is a SHOULD because it is information about the path. > > > > Cheers, > > Adrian > > >=20 > One additional comment of my own. For consistency, only LSR or node shou= ld > be used -- they are currently used about equally. I suggest replacing "L= SR" with > "node" . (Sorry, I thought we did this for this document already, but cl= early I > missed this due too much eggnog.) >=20 > Thanks, > Lou From nobody Thu Jan 8 03:57:45 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5517A1ACD0F for ; Thu, 8 Jan 2015 02:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 seHav2tG2egc for ; Thu, 8 Jan 2015 02:51:39 -0800 (PST) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD31ACD10 for ; Thu, 8 Jan 2015 02:51:38 -0800 (PST) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 8 Jan 2015 10:51:34 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%12]) with mapi id 14.03.0224.002; Thu, 8 Jan 2015 10:51:37 +0000 From: Ben Wright To: labn - Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" , "draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org" , Cyril Margaria Thread-Topic: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) Thread-Index: AQHQKptf5zkXqoy+kk+XdSQ3Q91m8Zy2DA5g Date: Thu, 8 Jan 2015 10:51:36 +0000 Message-ID: References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AC2352.6010900@labn.net> <54AD6610.5010205@labn.net> In-Reply-To: <54AD6610.5010205@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4001:73:cdb2:824b:206c:bd60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 08 Jan 2015 03:57:42 -0800 Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:51:41 -0000 Thanks Lou. I agree with your points. =20 On point 2) - Section 2.2 changes, the text here looks good to me. I'd add "The set of= valid flags are defined in section 4.3" as a forward reference to make lif= e easier for the reader.=20 - On the MIP and SRLG collection flags: I don't really see a requirement fo= r allowing them to be included in the LSP Hop Attributes subobject in the E= RO. In both cases I'd expect a network admin would always want to enable t= he function on all nodes on the path of an LSP. If someone has a good use = case for allowing these to be set differently on different hops, then it wo= uld be straightforward to raise a separate draft to describe the use case a= nd change this position. =20 On point 3) agree.=20 Other folks? Cyril - if you agree, are you OK to make these changes? Ben -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: 07 January 2015 17:00 To: adrian@olddog.co.uk; teas@ietf.org; draft-ietf-teas-lsp-attribute-ro.al= l@tools.ietf.org Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD r= eview draft-ietf-teas-rsvp-te-li-lb) [resend] All, I believe Adrian has identified a few issues with draft-ietf-teas-lsp-a= ttribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for c= ontext. In particular: 1) In the IANA section, the document states that Attribute Flags cannot be = carried in a LSP Hop Attributes subobject. It looks like this was a cut&pas= te bug introduced in rev 01 when translating the expanded directions into t= able form. The old -00 text in section 5.3.1 said: o Allowed on LSP attribute ERO subobject so the following change should= be made. OLD: 1 Attribute Flags Yes Yes No [RFC5420] NEW 1 Attribute Flags Yes Yes Yes [RFC5420] 2) Adrian points out that many existing flags really don't make sense in in= the LSP attribute ERO subobject and I think this should be documented. To = do this fully, I think we can either preclude usage of existing flags or al= low for specific flags (I could see allowing it for MIP, SRLG collection, b= ut am okay either way). Either way there should be an explicit statement o= n this, as well as a new column in the IANA table (with a new IANA section = describing this change). For the explicit statement, how about adding the following to the end of s= ection 2.2: The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject. Flags set in the an Attribute Flags TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be interpreted in the context of the received ERO. Only a subset of defined flags are defined as valid for use in Attribute Flags TLV carried in a ERO Hop Attributes Subobject. Invalid flags SHALL be silently ignored. Unknown flags SHOULD trigger the generation of a PathErr with Error Code "Unknown Attributes Bit" as defined in [RFC5420] Section 5.2. And 4.3. Existing Attribute Flags IANA manages the "Attribute Flags" registry as part of the "RSVP-TE PAR= AMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- parameters.xml. A new column in the registry is introduced by this document. This column indicates if the flag is permitted to be used in a Attribute Flags TLV carried in the ERO Hop Attributes Subobject. The column uses the heading "ERO" and the registery is to be updated as follows: Bit Name Attribute Attribute RRO ERO Reference FlagsPath FlagsResv 0 End-to-end re-routing Yes No No No [RFC4920] [RFC5420] 1 Boundary re-routing Yes No No No [RFC4920] [RFC5420] 2 Segment-based re-routing Yes No No No [RFC4920] [RFC5420] 3 LSP Integrity Required Yes No No No [RFC4875] 4 Contiguous LSP Yes No Yes No [RFC5151] 5 LSP stitching desired Yes No Yes No [RFC5150] 6 Pre-Planned LSP Flag Yes No No No [RFC6001] 7 Non-PHP behavior flag Yes No Yes No [RFC6511] 8 OOB mapping flag Yes No Yes No [RFC6511] 9 Entropy Label Capability Yes Yes No No [RFC6790] 10 OAM MEP entities desired Yes Yes Yes No [RFC7260] 11 OAM MIP entities desired Yes Yes Yes No [RFC7260] 12 SRLG collection Flag Yes Yes Yes No [draft-ietf- (TEMPORARY - registered ccamp-rsvp- 2014-09-11, expires te-srlg- 2015-09-11) collect] New allocation requests to this registry shall indicate the value to be = used in the ERO column. 3) the discussion also caught one naming inconsistency: s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject I think that's it. Comments? Lou On 1/6/2015 1:02 PM, Lou Berger wrote: > Adrian (all) > > On 1/6/2015 7:43 AM, Adrian Farrel wrote: > ... >>> You want to use a bit in the Attribute Flags TLV to indicate=20 >>> Loopback and propose including that TLV in the HOP Attributes ERO=20 >>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro. >>>> However, draft-ietf-teas-lsp-attribute-ro defines that the=20 >>>> Attributes Flags >> TLV is >>>> not allowed in the HOP Attributes ERO subobject. I think this is=20 >>>> for a good reason that many (all?) of bits defined so far have no=20 >>>> meaning if targeted >> at a >>>> specific transit LSR. >>> I guess there may be some confusion about this. Section 5.3.1 of >> draft-ietf-teas- >>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV,=20 >>> which says >> it is >>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the=20 >>> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute=20 >>> Subobject", thus my understanding is that the "Attributes Flags TLV"=20 >>> is allowed in the "ERO HOP Attribute subobject". >> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to=20 >> have changed a bit. >> >> The WG needs to work this through (no need to involve me :-). >> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D=20 >> needs to change. >> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to c= hange. > I this document is correct, and think you've identified a few issues=20 > with draft-ietf-teas-lsp-attribute-ro (which has also been submitted=20 > for > publication) and I'll start a new thread on these. > From nobody Thu Jan 8 08:48:45 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08CA1A87E4 for ; Thu, 8 Jan 2015 08:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 kMuqUGB-Mtvs for ; Thu, 8 Jan 2015 08:07:44 -0800 (PST) Received: from SFPETS2.metaswitch.com (sfpets2.metaswitch.com [198.147.226.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0BD1A8750 for ; Thu, 8 Jan 2015 08:07:43 -0800 (PST) Received: from SFPCAS1.datcon.co.uk (172.24.11.22) by SFPETS2.metaswitch.com (172.24.4.12) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 8 Jan 2015 08:07:16 -0800 Received: from SFPMBX1.datcon.co.uk ([fe80::8471:982f:7fd5:35ef]) by SFPCAS1.datcon.co.uk ([fe80::1924:e6dd:b536:8f10%12]) with mapi id 14.03.0224.002; Thu, 8 Jan 2015 08:07:42 -0800 From: Steve Balls To: Ben Wright , labn - Lou Berger , "adrian@olddog.co.uk" , "teas@ietf.org" , "draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org" , Cyril Margaria Thread-Topic: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) Thread-Index: AQHQKptfqpMhBEOH4kSoaAAPmIdNm5y2kwoA//+cRbA= Date: Thu, 8 Jan 2015 16:07:38 +0000 Deferred-Delivery: Thu, 8 Jan 2015 16:07:00 +0000 Message-ID: <1508F62A2F511042B45D315CFF74E2290163B7C1F4@SFPMBX1.datcon.co.uk> References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AC2352.6010900@labn.net> <54AD6610.5010205@labn.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4001:73:6582:c970:6dcd:9966] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 08 Jan 2015 08:48:41 -0800 Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:07:46 -0000 Similarly thanks Lou - I agree with Ben and have nothing to add. Steve -----Original Message----- From: Ben Wright [mailto:Ben.Wright@metaswitch.com]=20 Sent: 08 January 2015 10:52 To: labn - Lou Berger; adrian@olddog.co.uk; teas@ietf.org; draft-ietf-teas-= lsp-attribute-ro.all@tools.ietf.org; Cyril Margaria Subject: RE: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD r= eview draft-ietf-teas-rsvp-te-li-lb) Thanks Lou. I agree with your points. =20 On point 2) - Section 2.2 changes, the text here looks good to me. I'd add "The set of= valid flags are defined in section 4.3" as a forward reference to make lif= e easier for the reader.=20 - On the MIP and SRLG collection flags: I don't really see a requirement fo= r allowing them to be included in the LSP Hop Attributes subobject in the E= RO. In both cases I'd expect a network admin would always want to enable t= he function on all nodes on the path of an LSP. If someone has a good use = case for allowing these to be set differently on different hops, then it wo= uld be straightforward to raise a separate draft to describe the use case a= nd change this position. =20 On point 3) agree.=20 Other folks? Cyril - if you agree, are you OK to make these changes? Ben -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: 07 January 2015 17:00 To: adrian@olddog.co.uk; teas@ietf.org; draft-ietf-teas-lsp-attribute-ro.al= l@tools.ietf.org Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD r= eview draft-ietf-teas-rsvp-te-li-lb) [resend] All, I believe Adrian has identified a few issues with draft-ietf-teas-lsp-a= ttribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for c= ontext. In particular: 1) In the IANA section, the document states that Attribute Flags cannot be = carried in a LSP Hop Attributes subobject. It looks like this was a cut&pas= te bug introduced in rev 01 when translating the expanded directions into t= able form. The old -00 text in section 5.3.1 said: o Allowed on LSP attribute ERO subobject so the following change should= be made. OLD: 1 Attribute Flags Yes Yes No [RFC5420] NEW 1 Attribute Flags Yes Yes Yes [RFC5420] 2) Adrian points out that many existing flags really don't make sense in in= the LSP attribute ERO subobject and I think this should be documented. To = do this fully, I think we can either preclude usage of existing flags or al= low for specific flags (I could see allowing it for MIP, SRLG collection, b= ut am okay either way). Either way there should be an explicit statement o= n this, as well as a new column in the IANA table (with a new IANA section = describing this change). For the explicit statement, how about adding the following to the end of s= ection 2.2: The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject. Flags set in the an Attribute Flags TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be interpreted in the context of the received ERO. Only a subset of defined flags are defined as valid for use in Attribute Flags TLV carried in a ERO Hop Attributes Subobject. Invalid flags SHALL be silently ignored. Unknown flags SHOULD trigger the generation of a PathErr with Error Code "Unknown Attributes Bit" as defined in [RFC5420] Section 5.2. And 4.3. Existing Attribute Flags IANA manages the "Attribute Flags" registry as part of the "RSVP-TE PAR= AMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- parameters.xml. A new column in the registry is introduced by this document. This column indicates if the flag is permitted to be used in a Attribute Flags TLV carried in the ERO Hop Attributes Subobject. The column uses the heading "ERO" and the registery is to be updated as follows: Bit Name Attribute Attribute RRO ERO Reference FlagsPath FlagsResv 0 End-to-end re-routing Yes No No No [RFC4920] [RFC5420] 1 Boundary re-routing Yes No No No [RFC4920] [RFC5420] 2 Segment-based re-routing Yes No No No [RFC4920] [RFC5420] 3 LSP Integrity Required Yes No No No [RFC4875] 4 Contiguous LSP Yes No Yes No [RFC5151] 5 LSP stitching desired Yes No Yes No [RFC5150] 6 Pre-Planned LSP Flag Yes No No No [RFC6001] 7 Non-PHP behavior flag Yes No Yes No [RFC6511] 8 OOB mapping flag Yes No Yes No [RFC6511] 9 Entropy Label Capability Yes Yes No No [RFC6790] 10 OAM MEP entities desired Yes Yes Yes No [RFC7260] 11 OAM MIP entities desired Yes Yes Yes No [RFC7260] 12 SRLG collection Flag Yes Yes Yes No [draft-ietf- (TEMPORARY - registered ccamp-rsvp- 2014-09-11, expires te-srlg- 2015-09-11) collect] New allocation requests to this registry shall indicate the value to be = used in the ERO column. 3) the discussion also caught one naming inconsistency: s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject I think that's it. Comments? Lou On 1/6/2015 1:02 PM, Lou Berger wrote: > Adrian (all) > > On 1/6/2015 7:43 AM, Adrian Farrel wrote: > ... >>> You want to use a bit in the Attribute Flags TLV to indicate=20 >>> Loopback and propose including that TLV in the HOP Attributes ERO=20 >>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro. >>>> However, draft-ietf-teas-lsp-attribute-ro defines that the=20 >>>> Attributes Flags >> TLV is >>>> not allowed in the HOP Attributes ERO subobject. I think this is=20 >>>> for a good reason that many (all?) of bits defined so far have no=20 >>>> meaning if targeted >> at a >>>> specific transit LSR. >>> I guess there may be some confusion about this. Section 5.3.1 of >> draft-ietf-teas- >>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV,=20 >>> which says >> it is >>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the=20 >>> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute=20 >>> Subobject", thus my understanding is that the "Attributes Flags TLV" >>> is allowed in the "ERO HOP Attribute subobject". >> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to=20 >> have changed a bit. >> >> The WG needs to work this through (no need to involve me :-). >> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D=20 >> needs to change. >> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to c= hange. > I this document is correct, and think you've identified a few issues=20 > with draft-ietf-teas-lsp-attribute-ro (which has also been submitted=20 > for > publication) and I'll start a new thread on these. > From nobody Thu Jan 8 22:36:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2341A86E6; Thu, 8 Jan 2015 22:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bOwKcYxQnyNZ; Thu, 8 Jan 2015 22:36:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 572E11A0055; Thu, 8 Jan 2015 22:36:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109063615.10948.92987.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 22:36:15 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:36:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Authors : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-teas-rsvp-te-li-lb-02.txt Pages : 8 Date : 2015-01-08 Abstract: This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 22:41:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22931A7017 for ; Thu, 8 Jan 2015 22:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hQ66pCRrv3Z1 for ; Thu, 8 Jan 2015 22:41:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72631A0055 for ; Thu, 8 Jan 2015 22:41:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRA75618; Fri, 09 Jan 2015 06:41:35 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 Jan 2015 06:41:34 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 9 Jan 2015 14:41:31 +0800 From: "Dongjie (Jimmy)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt Thread-Index: AQHQK9aYJ5r7MYdZXEa1NTsPtxh96py3Va0Q Date: Fri, 9 Jan 2015 06:41:31 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927337F52F7@nkgeml512-mbx.china.huawei.com> References: <20150109063615.10948.92987.idtracker@ietfa.amsl.com> In-Reply-To: <20150109063615.10948.92987.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:41:40 -0000 Hi all,=20 This update is to solve the comments and suggestions made by Adrian and Lou= . Thanks. Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 09, 2015 2:36 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Traffic Engineering Architecture and Si= gnaling > Working Group of the IETF. >=20 > Title : GMPLS RSVP-TE Extensions for Lock Instruct and > Loopback > Authors : Jie Dong > Mach(Guoyi) Chen > Zhenqiang Li > Daniele Ceccarelli > Filename : draft-ietf-teas-rsvp-te-li-lb-02.txt > Pages : 8 > Date : 2015-01-08 >=20 > Abstract: > This document specifies extensions to Resource Reservation Protocol- > Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and > Loopback (LB) mechanisms for Label Switched Paths (LSPs). These > mechanisms are applicable to technologies which use Generalized > Multi-Protocol Label Switching (GMPLS) as control plane. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-li-lb-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Jan 9 05:10:18 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A561A8799 for ; Fri, 9 Jan 2015 05:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] autolearn=no 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 6DbdFztTLpf9 for ; Fri, 9 Jan 2015 05:10:03 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B10C1A8793 for ; Fri, 9 Jan 2015 05:10:01 -0800 (PST) Received: from localhost ([::1]:48172) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y9ZKB-0002fa-1P; Fri, 09 Jan 2015 16:09:59 +0300 Message-ID: <54AFD320.9060004@labn.net> Date: Fri, 09 Jan 2015 08:09:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dongjie (Jimmy)" , "teas@ietf.org" References: <20150109063615.10948.92987.idtracker@ietfa.amsl.com> <76CD132C3ADEF848BD84D028D243C927337F52F7@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927337F52F7@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 13:10:10 -0000 Jie, Thanks for the quick turn around. The changes look good to me (as doc Shepherd). I believe the ball is back in Adrian's court. Lou On 1/9/2015 1:41 AM, Dongjie (Jimmy) wrote: > Hi all, > > This update is to solve the comments and suggestions made by Adrian and Lou. Thanks. > > Best regards, > Jie > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, January 09, 2015 2:36 PM >> To: i-d-announce@ietf.org >> Cc: teas@ietf.org >> Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Traffic Engineering Architecture and Signaling >> Working Group of the IETF. >> >> Title : GMPLS RSVP-TE Extensions for Lock Instruct and >> Loopback >> Authors : Jie Dong >> Mach(Guoyi) Chen >> Zhenqiang Li >> Daniele Ceccarelli >> Filename : draft-ietf-teas-rsvp-te-li-lb-02.txt >> Pages : 8 >> Date : 2015-01-08 >> >> Abstract: >> This document specifies extensions to Resource Reservation Protocol- >> Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and >> Loopback (LB) mechanisms for Label Switched Paths (LSPs). These >> mechanisms are applicable to technologies which use Generalized >> Multi-Protocol Label Switching (GMPLS) as control plane. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Jan 9 06:15:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC91A8987 for ; Fri, 9 Jan 2015 06:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, 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 jczBPs2-2t7m for ; Fri, 9 Jan 2015 06:15:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CC71A8954 for ; Fri, 9 Jan 2015 06:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1420812913; x=1422022513; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sOdyTErJGGriDNRPC1k+mYtbcqcuR+lnfHop8VCqx78=; b=a1BF3/f3VqjFmdDXHH0WYkA1RCfOLwGwUmJQNtpNDTwPJGOpPcKPK7ax P+VORf5qDPaDm4NjEPqu2kEVyxLnv7IanR6NnwYyDYw0q8Rsl+g+rUfmP ED77R8SORWlpgMc5qiPTJJkDnjyFomQCBSG3176ZRUs/vz0D3A9axRZnb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAPrhr1StJV2S/2dsb2JhbABcgwZSWATDWoIlhXECgRRDAQEBAQF9hAwBAQEDATotEgUHBAIBCBEEAQEBHgUEBzIUCQgCBA4FCRCICwgNyQsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0YIKwcGgxCBEwWOOIkLgQ6NLIM6IoIygTxvAYECJB5+AQEB X-IronPort-AV: E=Sophos;i="5.07,731,1413244800"; d="scan'208";a="386017127" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jan 2015 14:15:12 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t09EFCTB021095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 14:15:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 08:15:12 -0600 From: "Giovanni Martinelli (giomarti)" To: Ben Wright Thread-Topic: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) Thread-Index: AQHQKpttO8OrUWn0D0OLAYct1GCEApy2cYMAgAHLOgA= Date: Fri, 9 Jan 2015 14:15:10 +0000 Message-ID: <7B8DDE01-C49E-4FA6-951D-F055C9A67523@cisco.com> References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AC2352.6010900@labn.net> <54AD6610.5010205@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.212.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <372CA899048C6149926198922E508FE4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Cyril Margaria , "adrian@olddog.co.uk" , Lou Berger , "draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org" , "teas@ietf.org" Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:15:16 -0000 from my side, same feeling as Ben here Cheers G On 08 Jan 2015, at 11:51, Ben Wright wrote: > Thanks Lou. I agree with your points. =20 >=20 > On point 2) > - Section 2.2 changes, the text here looks good to me. I'd add "The set = of valid flags are defined in section 4.3" as a forward reference to make l= ife easier for the reader.=20 >=20 > - On the MIP and SRLG collection flags: I don't really see a requirement = for allowing them to be included in the LSP Hop Attributes subobject in the= ERO. In both cases I'd expect a network admin would always want to enable= the function on all nodes on the path of an LSP. If someone has a good us= e case for allowing these to be set differently on different hops, then it = would be straightforward to raise a separate draft to describe the use case= and change this position. =20 >=20 > On point 3) agree.=20 >=20 > Other folks? Cyril - if you agree, are you OK to make these changes? >=20 > Ben >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: 07 January 2015 17:00 > To: adrian@olddog.co.uk; teas@ietf.org; draft-ietf-teas-lsp-attribute-ro.= all@tools.ietf.org > Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD= review draft-ietf-teas-rsvp-te-li-lb) >=20 > [resend] >=20 > All, > I believe Adrian has identified a few issues with draft-ietf-teas-lsp-= attribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for = context. In particular: >=20 > 1) In the IANA section, the document states that Attribute Flags cannot b= e carried in a LSP Hop Attributes subobject. It looks like this was a cut&p= aste bug introduced in rev 01 when translating the expanded directions into= table form. The old -00 text in section 5.3.1 said: > o Allowed on LSP attribute ERO subobject so the following change shoul= d be made. > OLD: > 1 Attribute Flags Yes Yes No [RFC5420] > NEW > 1 Attribute Flags Yes Yes Yes [RFC5420] >=20 > 2) Adrian points out that many existing flags really don't make sense in = in the LSP attribute ERO subobject and I think this should be documented. T= o do this fully, I think we can either preclude usage of existing flags or = allow for specific flags (I could see allowing it for MIP, SRLG collection,= but am okay either way). Either way there should be an explicit statement= on this, as well as a new column in the IANA table (with a new IANA sectio= n describing this change). >=20 > For the explicit statement, how about adding the following to the end of = section 2.2: >=20 > The Attribute Flags TLV defined in [RFC5420] MAY be carried in an > ERO Hop Attributes Subobject. Flags set in the an Attribute Flags > TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be > interpreted in the context of the received ERO. Only a subset of > defined flags are defined as valid for use in Attribute Flags TLV > carried in a ERO Hop Attributes Subobject. Invalid flags SHALL be > silently ignored. Unknown flags SHOULD trigger the generation of > a PathErr with Error Code "Unknown Attributes Bit" as defined in > [RFC5420] Section 5.2. >=20 > And > 4.3. Existing Attribute Flags >=20 > IANA manages the "Attribute Flags" registry as part of the "RSVP-TE PA= RAMETERS" registry located at > http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- > parameters.xml. A new column in the registry is introduced > by this document. This column indicates if the flag is permitted to be > used in a Attribute Flags TLV carried in the ERO Hop Attributes > Subobject. The column uses the heading "ERO" and the registery is > to be updated as follows: >=20 > Bit Name Attribute Attribute RRO ERO Reference > FlagsPath FlagsResv > 0 End-to-end re-routing Yes No No No [RFC4920] > [RFC5420] > 1 Boundary re-routing Yes No No No [RFC4920] > [RFC5420] > 2 Segment-based re-routing Yes No No No [RFC4920] > [RFC5420] > 3 LSP Integrity Required Yes No No No [RFC4875] > 4 Contiguous LSP Yes No Yes No [RFC5151] > 5 LSP stitching desired Yes No Yes No [RFC5150] > 6 Pre-Planned LSP Flag Yes No No No [RFC6001] > 7 Non-PHP behavior flag Yes No Yes No [RFC6511] > 8 OOB mapping flag Yes No Yes No [RFC6511] > 9 Entropy Label Capability Yes Yes No No [RFC6790] > 10 OAM MEP entities desired Yes Yes Yes No [RFC7260] > 11 OAM MIP entities desired Yes Yes Yes No [RFC7260] > 12 SRLG collection Flag Yes Yes Yes No [draft-ietf- > (TEMPORARY - registered ccamp-rsvp- > 2014-09-11, expires te-srlg- > 2015-09-11) collect] >=20 > New allocation requests to this registry shall indicate the value to be= used in the ERO column. >=20 > 3) the discussion also caught one naming inconsistency: > s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject >=20 > I think that's it. Comments? >=20 > Lou >=20 > On 1/6/2015 1:02 PM, Lou Berger wrote: >> Adrian (all) >>=20 >> On 1/6/2015 7:43 AM, Adrian Farrel wrote: >> ... >>>> You want to use a bit in the Attribute Flags TLV to indicate=20 >>>> Loopback and propose including that TLV in the HOP Attributes ERO=20 >>>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro. >>>>> However, draft-ietf-teas-lsp-attribute-ro defines that the=20 >>>>> Attributes Flags >>> TLV is >>>>> not allowed in the HOP Attributes ERO subobject. I think this is=20 >>>>> for a good reason that many (all?) of bits defined so far have no=20 >>>>> meaning if targeted >>> at a >>>>> specific transit LSR. >>>> I guess there may be some confusion about this. Section 5.3.1 of >>> draft-ietf-teas- >>>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV,=20 >>>> which says >>> it is >>>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the=20 >>>> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute=20 >>>> Subobject", thus my understanding is that the "Attributes Flags TLV"=20 >>>> is allowed in the "ERO HOP Attribute subobject". >>> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to=20 >>> have changed a bit. >>>=20 >>> The WG needs to work this through (no need to involve me :-). >>> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D=20 >>> needs to change. >>> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to = change. >> I this document is correct, and think you've identified a few issues=20 >> with draft-ietf-teas-lsp-attribute-ro (which has also been submitted=20 >> for >> publication) and I'll start a new thread on these. >>=20 >=20 From nobody Fri Jan 9 13:47:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA21A01E1 for ; Fri, 9 Jan 2015 13:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qikiXU1Z_-Fk for ; Fri, 9 Jan 2015 13:47:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B39B1A1A25 for ; Fri, 9 Jan 2015 13:47:26 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-c0-54afee4f13a9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C1.D0.25146.F4EEFA45; Fri, 9 Jan 2015 16:05:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 16:47:22 -0500 From: Gregory Mirsky To: "Rakesh Gandhi (rgandhi)" Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AQHQH/5YrpjNjKgiDky+ptAkRBgJ1Zyf6ZMQgBRb+YD//7QPAIAAYi0AgAQKzJA= Date: Fri, 9 Jan 2015 21:47:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8CD918@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B8CBBCF@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8CD918eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXSPn67/u/UhBisealscnz6BxWLF6WfM FhOPfGCx2LrkOJPF1KYONovWHztYLD6d+Mlk8XrHV3YHDo8pvzeyeuycdZfdY8mSn0weM3fO YfK4sVUxgDWKyyYlNSezLLVI3y6BK6Pn7X32gpPbmSpWzf3L3sB4qpupi5GTQ0LAROLg7JeM ELaYxIV769lAbCGBI4wSLXdiuhi5gOxljBKPHl4Ea2ATMJJ4sbGHHcQWETCUONy9mhWkiFlg KZNEY0sP2CRhgWCJM0/eAyU4gIpCJF5d84Oo95P41jQDbA6LgIrE/K/zwJbxCvhK3FlylBVi cZHEum33GUFaOQX0JVZvUQUJMwLd9v3UGrBWZgFxiVtP5kPdLyCxZM95ZghbVOLl43+sELai xL7+6ewQ9fkS7bP/MUKsEpQ4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewz Bx4zIYsvYGRfxchRWpxalptuZLiJERivxyTYHHcwLvhkeYhRgINRiYd3w+V1IUKsiWXFlbmH GKU5WJTEeSMerQ8REkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMildX+qwwbHK8xTu28dXv5p nevaC3POPQ57KLzKd21g2dV/JzgtZmpEMlyxD02v4vMPuxHS+MCSodTM45u9lPX/R7syXnUV VN858vthp5fNF85V0jN5Gdg+fUorPPnCT+Ke9fUfLspWIgIyn5N3VPpIFWxMEE65f0uttdNC 0Mv7hVeA3CN7LSWW4oxEQy3mouJEAMPPe2e4AgAA Archived-At: Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:47:47 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8CD918eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rakesh, apologies for the delay. In place of "protection switchover in both directions" perhaps "protection = of bi-directional co-routed LSPs" may be used. And couple other questions: * section Behavior Post Link Failure To Re-coroute describes actions = at R5 as finds ... if (found) ... ... But there's no discussion of what happens if "the bypass tunnel in th= e reverse direction that terminates on the Downstream PLR R3" cannot be fou= nd. Would such tunnel be signaled then? * revertive actions are not discussed in the document. I think they s= hould be discussed as support of revertive and non-revertive behaviors is r= equired for MPLS-TP networks. Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Tuesday, January 06, 2015 6:45 PM To: Gregory Mirsky Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); Zaf= ar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Gregory, Thank you for the context. Good stuff. May be we could state in the draft something along the line of: "PSC (RFC6378) is applicable to FRR (RFC4090) for local protection switchov= er in both directions in order to minimize traffic disruptions. In the abse= nce of such mechanism, control plane restoration proposed is required in or= der to avoid soft state time out". Would that work? thanks, Rakesh On 2015-01-06 9:18 PM, "Gregory Mirsky" > wrote: >Hi Rakesh, >thank you for your interest in my comments. >I can note that during work on MPLS-TP we, as union of MPLS and CCAMP >WGs, left question of RSVP FRR applicability undocumented. Perhaps we >can find mailing list discussions where some of us agreed that local >protection of uni-directional and bi-directional associated LSPs in >MPLS-TP can follow RFC 4090 but question of local protection of >bi-directional co-routed LSPs requires further discussion. And there >already were references to use ASSOCIATION object to support segment >protection if node protection desired. That would allow monitoring of >both working and protecting paths and switchover coordination by using >RFC 6378. >Of course, proposed mechanism is workable as control plane restoration >mechanism but I'm not convinced that is what should be standardized as >local protection mechanism. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Tuesday, January 06, 2015 5:26 PM >To: Gregory Mirsky >Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); >Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Hi Gregory, > >Thank you for your review comments. > >Can u please elaborate how does segment protection using ASSOCIATION >object solve the highlighted issue ? I am thinking such mechanisms >would apply to FRR as well. > >Thanks, >Rakesh > > >On 2014-12-25 2:51 AM, "Gregory Mirsky" > >wrote: > >>Dear All, >>I think that node protection mode for bidirectional co-routed LSP FRR >>is cumbersome and, at best, likely cause out-of-order delivery and >>more service disruption (switching reverse direction on R5 from R4 >>onto R3 triggered by tunneled RSVP Path message). I believe that >>extension of RFC >>4090 for bidirectional co-routed LSP FRR is viable only for link >>protection mode and node protection must be referred to segment >>protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >>Without such change in the scope of the draft I cannot support its >>adoption by the WG. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >>Sent: Wednesday, December 24, 2014 8:50 PM >>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>Cc: TEAS WG >>Subject: Re: [Teas] Mail regarding >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> >>Working Group, >> >>I was almost through my review of this document, saw Nobo's review and >>found that he had found everything I found and a bit more :). >> >>With that and with Rakesh's statement that the comments will be >>addressed I souppor the adoption of the document as a wg doc. >> >>/Loa >> >>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >>> Thank you Nobo for your detailed review comments. >>> >>> We will address these in the next revision. >>> >>> Happy holidays. >>> >>> Thanks, >>> Rakesh >>> >>> >>> From: "Nobo Akiya (nobo)" >> >>> Date: Wednesday, 24 December, 2014 5:45 PM >>> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>> " >>> >> >> g >>> > >>> > >>> Cc: TEAS WG >> >>> Subject: Mail regarding >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>> Resent-From: >> > >>> Resent-To: "frederic.jounay@orange.ch >>>" >>>, "Lizhong com>" >>> >>, >>>>>, >>>"=3DSMTP:mtaillon@cisco. com" >>> >>, Rakesh Gandhi >>>>>, >>>, Zafar Ali >>> >>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >>> >>> Hi Authors, >>> >>> Happy Holidays! >>> >>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of >>>its WG adoption poll), and had some questions/comments. Please find >>>them below. >>> >>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may >>> be easier to understand if "list" is used. >>> >>> [OLD] >>> >>> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >>> object >>> >>> prior to adding the node's IP address in the node-ID subobject. >>> A >>> >>> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also >>> adding a >>> >>> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >>> subobject >>> >>> without also adding an IPv4 or IPv6 subobject. >>> >>> [NEW] >>> >>> When the BYPASS_ASSIGNMENT subobject is added in the >>> RECORD_ROUTE >>> >>> object: >>> >>> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >>> node-ID >>> >>> subobject describing the node's IP address. >>> >>> o The Node-ID subobject MUST also be added. >>> >>> o The IPv4 or IPv6 subobject MUST also be added. >>> >>> 2) Section 4.4.1 - First sentence of the third paragraph was quite >>> difficult to read/understand. Perhaps adding some commas and >>> quotations may improve its readability. >>> >>> [OLD] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a bypass tunnel source terminates locally assigns the matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> [NEW] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject, whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a "bypass tunnel source" terminates locally, assigns the >>> matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> 3) Section 4.4.1 - I have a slight concern regarding below statement. >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >>> >>> subobjects from multiple downstream PLRs, the decision of >>> selecting a >>> >>> bypass tunnel in the reverse direction can be based on local >>> policy, >>> >>> for example, prefer link protection versus node protection >>> bypass >>> >>> tunnel, or prefer the most upstream versus least upstream node >>> >>> protection bypass tunnel. >>> >>> [snip] >>> >>> When LSRs within a bidirectional LSP employ different policies, as >>> described above, then we can result in pockets where there are no >>> protections. >>> >>> For example: >>> >>> Node A uses node protection. >>> >>> Node B and C use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +-+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> Another example: >>> >>> Node A and C use node protection. >>> >>> Node B use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +----------+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> In both cases, if there is a breakage of the link connecting nodes A >>> and B, then node C receives the RSVP PATH message. If node C follows >>> procedures described in Section 6.2, then it will not find a >>> matching bypass tunnel. >>> >>> If I'm off track, then I apologize for the noise. If above is indeed >>> a problem, then this limitation should at least be described in the >>> document, followed by a recommendation of all LSRs within a >>> bidirectional tunnel employing the same policy. >>> >>> It may be possible to (be brave and) address this but it will >>> require more procedures. I'll leave the decision and further >>> investigation to the authors. >>> >>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> [snip] >>> >>> I'm guessing that there should be a SHOULD ... >>> >>> 5) Section 6.2 - "If" and "If not" in below text do not correspond >>> to each other (thus a bit confusing). >>> >>> [snip] >>> >>> - If found, checks whether the primary LSP traffic and >>> signaling >>> >>> are already rerouted over the found bypass tunnel. If not, >>> PRR >>> >>> R5 activates FRR reroute procedures to direct traffic and >>> >>> RSVP Resv over the found bypass tunnel T2 in the >>> >>> reverse direction. >>> >>> [snip] >>> >>> If we write above with a psuedocode, then it will be: >>> >>> if (bypass tunnel found) { // "If found" is this line >>> >>> check if already rerouted >>> >>> if (not already rerouted) { // "If not" is this line >>> >>> active FRR reroute >>> >>> } >>> >>> } >>> >>> It might make the texts easier to read/understand if you can >>> rephrase it a bit? >>> >>> Thanks! >>> >>> -Nobo >>> >>> >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>Teas mailing list >>Teas@ietf.org >>https://www.ietf.org/mailman/listinfo/teas > --_000_7347100B5761DC41A166AC17F22DF1121B8CD918eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rakesh,
apologies for the delay.
In place of "protection switchover in both directions" perha= ps "protection of bi-directional co-routed LSPs" may be used.
And couple other questions:
  • section Behavior Post Link Failure To Re-coroute describes actions at R= 5 as
finds …
if (found) …
   …
But there's no discussion of what happens= if "the bypass tunnel in the reverse direction that terminates on the= Downstream PLR R3" cannot be found. Would such tunnel be signaled the= n?
  • revertive actions are not discussed in the document. I think they shoul= d be discussed as support of revertive and non-revertive behaviors is requi= red for MPLS-TP networks.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:= rgandhi@cisco.com]
Sent: Tuesday, January 06, 2015 6:45 PM
To: Gregory Mirsky
Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); = Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch
Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute
 
Hi Gregory,
 
Thank you for the context. Good stuff.
 
May be we could state in the draft something along the line of:
"PSC (RFC6378) is applicable to FRR (RFC4090) for local protectio= n switchover in both directions in order to minimize traffic disruptions. I= n the absence of such mechanism, control plane restoration proposed is requ= ired in order to avoid soft state time out".
 
Would that work?
 
thanks,
Rakesh
 
 
 
On 2015-01-06 9:18 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
wrote:
 
>Hi Rakesh,
>thank you for your interest in my comments.
>I can note that during work on MPLS-TP we, as union of MPLS and CC= AMP
>WGs, left question of RSVP FRR applicability undocumented. Perhaps= we
>can find mailing list discussions where some of us agreed that loc= al
>protection of uni-directional and bi-directional associated LSPs i= n
>MPLS-TP can follow RFC 4090 but question of local protection of
>bi-directional co-routed LSPs requires further discussion. And the= re
>already were references to use ASSOCIATION object to support segme= nt
>protection if node protection desired. That would allow monitoring= of
>both working and protecting paths and switchover coordination by u= sing
>RFC 6378.
>Of course, proposed mechanism is workable as control plane restora= tion
>mechanism but I'm not convinced that is what should be standardize= d as
>local protection mechanism.
>
>       Regards,
>           =     Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>Sent: Tuesday, January 06, 2015 5:26 PM
>To: Gregory Mirsky
>Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mt= aillon);
>Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch
>Subject: Re: [Teas] Mail regarding
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>
>Hi Gregory,
>
>Thank you for your review comments.
>
>Can u please elaborate how does segment protection using ASSOCIATI= ON
>object solve the highlighted issue ?  I am thinking such mech= anisms
>would apply to FRR as well.
>
>Thanks,
>Rakesh
>
>
>On 2014-12-25 2:51 AM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
>wrote:
>
>>Dear All,
>>I think that node protection mode for bidirectional co-routed = LSP FRR
>>is cumbersome and, at best, likely cause out-of-order delivery= and
>>more service disruption (switching reverse direction on R5 fro= m R4
>>onto R3 triggered by tunneled RSVP Path message). I believe th= at
>>extension of RFC
>>4090 for bidirectional co-routed LSP FRR is viable only for li= nk
>>protection mode and node protection must be referred to segmen= t
>>protection and use of RSVP ASSOCIATION object (RFC 4872 and RF= C 6689).
>>Without such change in the scope of the draft I cannot support= its
>>adoption by the WG.
>>
>>      Regards,
>>          &n= bsp;   Greg
>>
>>-----Original Message-----
>>From: Teas [mailto:te= as-bounces@ietf.org] On Behalf Of Loa Andersson
>>Sent: Wednesday, December 24, 2014 8:50 PM
>>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);
>>Cc: TEAS WG
>>Subject: Re: [Teas] Mail regarding
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>
>>Working Group,
>>
>>I was almost through my review of this document, saw Nobo's re= view and
>>found that he had found everything I found and a bit more :).<= /div>
>>
>>With that and with Rakesh's statement that the comments will b= e
>>addressed I souppor the adoption of the document as a wg doc.<= /div>
>>
>>/Loa
>>
>>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote:
>>> Thank you Nobo for your detailed review comments.
>>>
>>> We will address these in the next revision.
>>>
>>> Happy holidays.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> From: "Nobo Akiya (nobo)" <nobo@cisco.com <mailto:nobo@c= isco.com>>
>>> Date: Wednesday, 24 December, 2014 5:45 PM
>>> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@= tools.ietf.org
>>> <draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.= ietf.org
>>> <mailto:draft-tsaad-ccamp-rsvpte-bidi= r-lsp-fastreroute@tools.ietf.or
>>> g
>>> >
>>> >
>>> Subject: Mail regarding
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>> Resent-From: <draft-alias-bounces@tools.ietf.org
>>> Resent-To: "frederic.jounay@orange.ch
>>><mailto:fr= ederic.jounay@orange.ch>" <frederic.jounay@orange.ch
>>>"=3DSMTP:mtaillon@cisco. com"
>>><mailto:tsaad@cisco.= com>>, Zafar Ali <zali@cisco.com
>>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM
>>>
>>> Hi Authors,
>>>
>>> Happy Holidays!
>>>
>>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 = (as part of
>>>its WG adoption poll), and had some questions/comments. Pl= ease find
>>>them below.
>>>
>>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT su= bobject may
>>> be easier to understand if "list" is used.
>>>
>>> [OLD]
>>>
>>>     The BYPASS_ASSIGNMENT subobject i= s added in the RECORD_ROUTE
>>> object
>>>
>>>     prior to adding the node's IP add= ress in the node-ID subobject.
>>> A
>>>
>>>     node MUST NOT add a BYPASS_ASSIGN= MENT subobject without also
>>> adding a
>>>
>>>     Node-ID subobject.  A node M= UST NOT add a BYPASS_ASSIGNMENT
>>> subobject
>>>
>>>     without also adding an IPv4 or IP= v6 subobject.
>>>
>>> [NEW]
>>>
>>>     When the BYPASS_ASSIGNMENT subobj= ect is added in the
>>> RECORD_ROUTE
>>>
>>>     object:
>>>
>>>     o  The BYPASS_ASSIGNMENT sub= object MUST be added prior to the
>>> node-ID
>>>
>>>        subobject descr= ibing the node's IP address.
>>>
>>>     o  The Node-ID subobject MUS= T also be added.
>>>
>>>     o  The IPv4 or IPv6 subobjec= t MUST also be added.
>>>
>>> 2) Section 4.4.1 - First sentence of the third paragraph = was quite
>>> difficult to read/understand. Perhaps adding some commas = and
>>> quotations may improve its readability.
>>>
>>> [OLD]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject whose bypass tunnel and= the node-ID subobject when
>>> used as
>>>
>>>     a bypass tunnel source terminates= locally assigns the matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> [NEW]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject, whose bypass tunnel an= d the node-ID subobject when
>>> used as
>>>
>>>     a "bypass tunnel source"= ; terminates locally, assigns the
>>> matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> 3) Section 4.4.1 - I have a slight concern regarding belo= w statement.
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>>     In the case of upstream PLR recei= ving multiple BYPASS_ASSIGNMENT
>>>
>>>     subobjects from multiple downstre= am PLRs, the decision of
>>> selecting a
>>>
>>>     bypass tunnel in the reverse dire= ction can be based on local
>>> policy,
>>>
>>>     for example, prefer link protecti= on versus node protection
>>> bypass
>>>
>>>     tunnel, or prefer the most upstre= am versus least upstream node
>>>
>>>     protection bypass tunnel.
>>>
>>> [snip]
>>>
>>> When LSRs within a bidirectional LSP employ different pol= icies, as
>>> described above, then we can result in pockets where ther= e are no
>>> protections.
>>>
>>> For example:
>>>
>>> Node A uses node protection.
>>>
>>> Node B and C use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>>         &nbs= p; ^     /
>>>
>>>         &nbs= p;  \   /
>>>
>>>         &nbs= p;   +-+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> Another example:
>>>
>>> Node A and C use node protection.
>>>
>>> Node B use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>> ^         &n= bsp;    /
>>>
>>>    \      &n= bsp;     /
>>>
>>>     +----------+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> In both cases, if there is a breakage of the link connect= ing nodes A
>>> and B, then node C receives the RSVP PATH message. If nod= e C follows
>>> procedures described in Section 6.2, then it will not fin= d a
>>> matching bypass tunnel.
>>>
>>> If I'm off track, then I apologize for the noise. If abov= e is indeed
>>> a problem, then this limitation should at least be descri= bed in the
>>> document, followed by a recommendation of all LSRs within= a
>>> bidirectional tunnel employing the same policy.
>>>
>>> It may be possible to (be brave and) address this but it = will
>>> require more procedures. I'll leave the decision and furt= her
>>> investigation to the authors.
>>>
>>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this= paragraph?
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>> [snip]
>>>
>>> I'm guessing that there should be a SHOULD ...
>>>
>>> 5) Section 6.2 - "If" and "If not" in= below text do not correspond
>>> to each other (thus a bit confusing).
>>>
>>> [snip]
>>>
>>>        - If found, che= cks whether the primary LSP traffic and
>>> signaling
>>>
>>>          are= already rerouted over the found bypass tunnel.  If not,
>>> PRR
>>>
>>>          R5 = activates FRR reroute procedures to direct traffic and
>>>
>>>          RSV= P Resv over the found bypass tunnel T2 in the
>>>
>>>          rev= erse direction.
>>>
>>> [snip]
>>>
>>> If we write above with a psuedocode, then it will be:
>>>
>>>      if (bypass tunnel found) {&= nbsp;     // "If found" is this line
>>>
>>>          che= ck if already rerouted
>>>
>>>          if = (not already rerouted) { // "If not" is this line
>>>
>>>         &nbs= p;     active FRR reroute
>>>
>>>          }
>>>
>>>      }
>>>
>>> It  might make the texts easier to read/understand i= f you can
>>> rephrase it a bit?
>>>
>>> Thanks!
>>>
>>> -Nobo
>>>
>>>
>>>
>>> _______________________________________________
>>> Teas mailing list
>>>
>>
>>--
>>
>>
>>Loa Andersson        &= nbsp;           &nbs= p;   email: loa@mail01.h= uawei.com
>>Senior MPLS Expert       &n= bsp;            = ;      loa@pi.nu<= /div>
>>Huawei Technologies (consultant)     phone= : +46 739 81 21 64
>>
>>_______________________________________________
>>Teas mailing list
>
 
 
--_000_7347100B5761DC41A166AC17F22DF1121B8CD918eusaamb103erics_-- From nobody Fri Jan 9 14:01:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075A41A1A73 for ; Fri, 9 Jan 2015 14:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 viB8v2LS37-7 for ; Fri, 9 Jan 2015 14:01:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB551A1A7E for ; Fri, 9 Jan 2015 14:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45012; q=dns/txt; s=iport; t=1420840890; x=1422050490; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=+MkHrJ+QAVZStdUZnjfyqSo6GH4/oNSusYzyrn0hOYI=; b=R1FY+yIR3JkoE+i3vhG9pdvhRzn1IfhIMyG9BVLV+291zPyPqJ3nfYmH 2Ps+qjCXVmQLYt7wM6LyID3c7ujomZOpdx3qy0p6HuwYY0Fd8Q3a+OnRj HVfO+sg5Zy+hvktULUXwIGVZNn4qMe/145S4/BkiA6HzrEK9N8kr0uhd0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADZPsFStJA2K/2dsb2JhbABcgkNDUlgExWAZAQmFcQKBFUMBAQEBAX2EDAEBAQMBAQEBFxMaJAMLBQcCBAEIEQMBAQEBIAEGIgYGCxQJCAIEDgWIGAMJCA28EIpVDYNaAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEjUuBSBACASMBBxMNBAcGhCMFhTUshnyBW4VJgX6BRIEOgnGCOIVcgieDOiKDbm8BAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,733,1413244800"; d="scan'208,217";a="385798569" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jan 2015 22:01:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t09M1SAC017657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 22:01:28 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 16:01:28 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6AABXMfIAABlTzgAJ11UUAAAxUN4D//7OagIAEt5KA//+wFwA= Date: Fri, 9 Jan 2015 22:01:27 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8CD918@eusaamb103.ericsson.se> 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: [161.44.212.215] Content-Type: multipart/alternative; boundary="_000_D0D5B74A49E38rgandhiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:01:37 -0000 --_000_D0D5B74A49E38rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gregory, Thank you for your review comments. Please see inline .. .. From: Gregory Mirsky > Date: Friday, 9 January, 2015 4:47 PM To: Rakesh Gandhi > Cc: TEAS WG >, "Tarek Saad (tsaad)" >, "Lizhong com>" >, "=3DSMTP:mtaillon@cisco. com" >, Zafar Ali >, Manav Bhatia >, "frederic.jounay@orange.ch" > Subject: RE: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Rakesh, apologies for the delay. In place of "protection switchover in both directions" perhaps "protection = of bi-directional co-routed LSPs" may be used. Ack. And couple other questions: * section Behavior Post Link Failure To Re-coroute describes actions at= R5 as finds =85 if (found) =85 =85 But there's no discussion of what happens if "the bypass tunnel in the reve= rse direction that terminates on the Downstream PLR R3" cannot be found. Wo= uld such tunnel be signaled then? Yes, in such a case, downstream MP can assign a reverse bypass tunnel = and if does not exist, can create it. We can add this in the draft. * revertive actions are not discussed in the document. I think they sho= uld be discussed as support of revertive and non-revertive behaviors is req= uired for MPLS-TP networks. Ok, we will discuss among authors and propose it in the draft. thanks, Rakesh Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Tuesday, January 06, 2015 6:45 PM To: Gregory Mirsky Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); Zaf= ar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Gregory, Thank you for the context. Good stuff. May be we could state in the draft something along the line of: "PSC (RFC6378) is applicable to FRR (RFC4090) for local protection switchov= er in both directions in order to minimize traffic disruptions. In the abse= nce of such mechanism, control plane restoration proposed is required in or= der to avoid soft state time out". Would that work? thanks, Rakesh On 2015-01-06 9:18 PM, "Gregory Mirsky" > wrote: >Hi Rakesh, >thank you for your interest in my comments. >I can note that during work on MPLS-TP we, as union of MPLS and CCAMP >WGs, left question of RSVP FRR applicability undocumented. Perhaps we >can find mailing list discussions where some of us agreed that local >protection of uni-directional and bi-directional associated LSPs in >MPLS-TP can follow RFC 4090 but question of local protection of >bi-directional co-routed LSPs requires further discussion. And there >already were references to use ASSOCIATION object to support segment >protection if node protection desired. That would allow monitoring of >both working and protecting paths and switchover coordination by using >RFC 6378. >Of course, proposed mechanism is workable as control plane restoration >mechanism but I'm not convinced that is what should be standardized as >local protection mechanism. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Tuesday, January 06, 2015 5:26 PM >To: Gregory Mirsky >Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); >Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Hi Gregory, > >Thank you for your review comments. > >Can u please elaborate how does segment protection using ASSOCIATION >object solve the highlighted issue ? I am thinking such mechanisms >would apply to FRR as well. > >Thanks, >Rakesh > > >On 2014-12-25 2:51 AM, "Gregory Mirsky" > >wrote: > >>Dear All, >>I think that node protection mode for bidirectional co-routed LSP FRR >>is cumbersome and, at best, likely cause out-of-order delivery and >>more service disruption (switching reverse direction on R5 from R4 >>onto R3 triggered by tunneled RSVP Path message). I believe that >>extension of RFC >>4090 for bidirectional co-routed LSP FRR is viable only for link >>protection mode and node protection must be referred to segment >>protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >>Without such change in the scope of the draft I cannot support its >>adoption by the WG. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >>Sent: Wednesday, December 24, 2014 8:50 PM >>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>Cc: TEAS WG >>Subject: Re: [Teas] Mail regarding >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> >>Working Group, >> >>I was almost through my review of this document, saw Nobo's review and >>found that he had found everything I found and a bit more :). >> >>With that and with Rakesh's statement that the comments will be >>addressed I souppor the adoption of the document as a wg doc. >> >>/Loa >> >>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >>> Thank you Nobo for your detailed review comments. >>> >>> We will address these in the next revision. >>> >>> Happy holidays. >>> >>> Thanks, >>> Rakesh >>> >>> >>> From: "Nobo Akiya (nobo)" >> >>> Date: Wednesday, 24 December, 2014 5:45 PM >>> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>> " >>> >>> >> g >>> > >>> > >>> Cc: TEAS WG >> >>> Subject: Mail regarding >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>> Resent-From: >>> > >>> Resent-To: "frederic.jounay@orange.ch >>>" >>>>, "Lizhong com>" >>> >>, >>>>>, >>>"=3DSMTP:mtaillon@cisco. com" >>> >>, Rakesh Gandhi >>>>>, >>>>, Zafar Ali >>>> >>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >>> >>> Hi Authors, >>> >>> Happy Holidays! >>> >>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of >>>its WG adoption poll), and had some questions/comments. Please find >>>them below. >>> >>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may >>> be easier to understand if "list" is used. >>> >>> [OLD] >>> >>> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >>> object >>> >>> prior to adding the node's IP address in the node-ID subobject. >>> A >>> >>> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also >>> adding a >>> >>> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >>> subobject >>> >>> without also adding an IPv4 or IPv6 subobject. >>> >>> [NEW] >>> >>> When the BYPASS_ASSIGNMENT subobject is added in the >>> RECORD_ROUTE >>> >>> object: >>> >>> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >>> node-ID >>> >>> subobject describing the node's IP address. >>> >>> o The Node-ID subobject MUST also be added. >>> >>> o The IPv4 or IPv6 subobject MUST also be added. >>> >>> 2) Section 4.4.1 - First sentence of the third paragraph was quite >>> difficult to read/understand. Perhaps adding some commas and >>> quotations may improve its readability. >>> >>> [OLD] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a bypass tunnel source terminates locally assigns the matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> [NEW] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject, whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a "bypass tunnel source" terminates locally, assigns the >>> matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> 3) Section 4.4.1 - I have a slight concern regarding below statement. >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >>> >>> subobjects from multiple downstream PLRs, the decision of >>> selecting a >>> >>> bypass tunnel in the reverse direction can be based on local >>> policy, >>> >>> for example, prefer link protection versus node protection >>> bypass >>> >>> tunnel, or prefer the most upstream versus least upstream node >>> >>> protection bypass tunnel. >>> >>> [snip] >>> >>> When LSRs within a bidirectional LSP employ different policies, as >>> described above, then we can result in pockets where there are no >>> protections. >>> >>> For example: >>> >>> Node A uses node protection. >>> >>> Node B and C use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +-+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> Another example: >>> >>> Node A and C use node protection. >>> >>> Node B use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +----------+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> In both cases, if there is a breakage of the link connecting nodes A >>> and B, then node C receives the RSVP PATH message. If node C follows >>> procedures described in Section 6.2, then it will not find a >>> matching bypass tunnel. >>> >>> If I'm off track, then I apologize for the noise. If above is indeed >>> a problem, then this limitation should at least be described in the >>> document, followed by a recommendation of all LSRs within a >>> bidirectional tunnel employing the same policy. >>> >>> It may be possible to (be brave and) address this but it will >>> require more procedures. I'll leave the decision and further >>> investigation to the authors. >>> >>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> [snip] >>> >>> I'm guessing that there should be a SHOULD ... >>> >>> 5) Section 6.2 - "If" and "If not" in below text do not correspond >>> to each other (thus a bit confusing). >>> >>> [snip] >>> >>> - If found, checks whether the primary LSP traffic and >>> signaling >>> >>> are already rerouted over the found bypass tunnel. If not, >>> PRR >>> >>> R5 activates FRR reroute procedures to direct traffic and >>> >>> RSVP Resv over the found bypass tunnel T2 in the >>> >>> reverse direction. >>> >>> [snip] >>> >>> If we write above with a psuedocode, then it will be: >>> >>> if (bypass tunnel found) { // "If found" is this line >>> >>> check if already rerouted >>> >>> if (not already rerouted) { // "If not" is this line >>> >>> active FRR reroute >>> >>> } >>> >>> } >>> >>> It might make the texts easier to read/understand if you can >>> rephrase it a bit? >>> >>> Thanks! >>> >>> -Nobo >>> >>> >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>Teas mailing list >>Teas@ietf.org >>https://www.ietf.org/mailman/listinfo/teas > --_000_D0D5B74A49E38rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <033F95FB3466A14EB8386839781002E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Gregory,

Thank you for your review comments. 

Please see inline .. <RG>..

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Friday, 9 January, 2015 4:47 = PM
To: Rakesh Gandhi <rgandhi@cisco.com>
Cc: TEAS WG <teas@ietf.org>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "Lizhong com&= gt;" <lizho.jin@gmail.com>, "=3DSMTP:mtaillon@cisco. com" <mtaillon@cisco.com>, Zafar Ali <zali@cisco.com>, Manav Bhatia <manav@ionosnetworks.com>, "frederic.jounay@orange.ch" <frederic.jounay@orange.ch= >
Subject: RE: [Teas] Mail regarding = draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

Hi Rakesh,
apologies for the delay.
In place of "protection switchover in both directions" perha= ps "protection of bi-directional co-routed LSPs" may be used.

<RG> Ack.

And couple other questions:
  • section Behavior Post Link Failure To Re-coroute describes actions at R= 5 as
finds =85
if (found) =85
   =85
But there's no discussion of what happens= if "the bypass tunnel in the reverse direction that terminates on the= Downstream PLR R3" cannot be found. Would such tunnel be signaled the= n?

<RG> Yes, in such a case, downstream MP can assign a reverse byp= ass tunnel and if does not exist, can create it. We can add this in the dra= ft.

  • revertive actions are not discussed in the document. I think they shoul= d be discussed as support of revertive and non-revertive behaviors is requi= red for MPLS-TP networks.
<RG> Ok, we will discuss among authors and propose it in the dra= ft.

thanks,
Rakesh
 
 

        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:= rgandhi@cisco.com]
Sent: Tuesday, January 06, 2015 6:45 PM
To: Gregory Mirsky
Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); = Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch<= br> Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute
 
Hi Gregory,
 
Thank you for the context. Good stuff.
 
May be we could state in the draft something along the line of:
"PSC (RFC6378) is applicable to FRR (RFC4090) for local protectio= n switchover in both directions in order to minimize traffic disruptions. I= n the absence of such mechanism, control plane restoration proposed is requ= ired in order to avoid soft state time out".
 
Would that work?
 
thanks,
Rakesh
 
 
 
On 2015-01-06 9:18 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
wrote:
 
>Hi Rakesh,
>thank you for your interest in my comments.
>I can note that during work on MPLS-TP we, as union of MPLS and CC= AMP
>WGs, left question of RSVP FRR applicability undocumented. Perhaps= we
>can find mailing list discussions where some of us agreed that loc= al
>protection of uni-directional and bi-directional associated LSPs i= n
>MPLS-TP can follow RFC 4090 but question of local protection of
>bi-directional co-routed LSPs requires further discussion. And the= re
>already were references to use ASSOCIATION object to support segme= nt
>protection if node protection desired. That would allow monitoring= of
>both working and protecting paths and switchover coordination by u= sing
>RFC 6378.
>Of course, proposed mechanism is workable as control plane restora= tion
>mechanism but I'm not convinced that is what should be standardize= d as
>local protection mechanism.
>
>       Regards,
>           =     Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>Sent: Tuesday, January 06, 2015 5:26 PM
>To: Gregory Mirsky
>Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mt= aillon);
>Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch
>Subject: Re: [Teas] Mail regarding
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>
>Hi Gregory,
>
>Thank you for your review comments.
>
>Can u please elaborate how does segment protection using ASSOCIATI= ON
>object solve the highlighted issue ?  I am thinking such mech= anisms
>would apply to FRR as well.
>
>Thanks,
>Rakesh
>
>
>On 2014-12-25 2:51 AM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
>wrote:
>
>>Dear All,
>>I think that node protection mode for bidirectional co-routed = LSP FRR
>>is cumbersome and, at best, likely cause out-of-order delivery= and
>>more service disruption (switching reverse direction on R5 fro= m R4
>>onto R3 triggered by tunneled RSVP Path message). I believe th= at
>>extension of RFC
>>4090 for bidirectional co-routed LSP FRR is viable only for li= nk
>>protection mode and node protection must be referred to segmen= t
>>protection and use of RSVP ASSOCIATION object (RFC 4872 and RF= C 6689).
>>Without such change in the scope of the draft I cannot support= its
>>adoption by the WG.
>>
>>      Regards,
>>          &n= bsp;   Greg
>>
>>-----Original Message-----
>>From: Teas [mailto:te= as-bounces@ietf.org] On Behalf Of Loa Andersson
>>Sent: Wednesday, December 24, 2014 8:50 PM
>>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);
>>Cc: TEAS WG
>>Subject: Re: [Teas] Mail regarding
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>
>>Working Group,
>>
>>I was almost through my review of this document, saw Nobo's re= view and
>>found that he had found everything I found and a bit more :).<= /div>
>>
>>With that and with Rakesh's statement that the comments will b= e
>>addressed I souppor the adoption of the document as a wg doc.<= /div>
>>
>>/Loa
>>
>>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote:
>>> Thank you Nobo for your detailed review comments.
>>>
>>> We will address these in the next revision.
>>>
>>> Happy holidays.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> From: "Nobo Akiya (nobo)" <nobo@cisco.com <mailto:nobo@c= isco.com>>
>>> Date: Wednesday, 24 December, 2014 5:45 PM
>>> g
>>> >
>>> >
>>> Subject: Mail regarding
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>> Resent-To: "frederic.jounay@orange.ch
>>>"=3DSMTP:mtaillon@cisco. com"
>>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM
>>>
>>> Hi Authors,
>>>
>>> Happy Holidays!
>>>
>>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 = (as part of
>>>its WG adoption poll), and had some questions/comments. Pl= ease find
>>>them below.
>>>
>>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT su= bobject may
>>> be easier to understand if "list" is used.
>>>
>>> [OLD]
>>>
>>>     The BYPASS_ASSIGNMENT subobject i= s added in the RECORD_ROUTE
>>> object
>>>
>>>     prior to adding the node's IP add= ress in the node-ID subobject.
>>> A
>>>
>>>     node MUST NOT add a BYPASS_ASSIGN= MENT subobject without also
>>> adding a
>>>
>>>     Node-ID subobject.  A node M= UST NOT add a BYPASS_ASSIGNMENT
>>> subobject
>>>
>>>     without also adding an IPv4 or IP= v6 subobject.
>>>
>>> [NEW]
>>>
>>>     When the BYPASS_ASSIGNMENT subobj= ect is added in the
>>> RECORD_ROUTE
>>>
>>>     object:
>>>
>>>     o  The BYPASS_ASSIGNMENT sub= object MUST be added prior to the
>>> node-ID
>>>
>>>        subobject descr= ibing the node's IP address.
>>>
>>>     o  The Node-ID subobject MUS= T also be added.
>>>
>>>     o  The IPv4 or IPv6 subobjec= t MUST also be added.
>>>
>>> 2) Section 4.4.1 - First sentence of the third paragraph = was quite
>>> difficult to read/understand. Perhaps adding some commas = and
>>> quotations may improve its readability.
>>>
>>> [OLD]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject whose bypass tunnel and= the node-ID subobject when
>>> used as
>>>
>>>     a bypass tunnel source terminates= locally assigns the matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> [NEW]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject, whose bypass tunnel an= d the node-ID subobject when
>>> used as
>>>
>>>     a "bypass tunnel source"= ; terminates locally, assigns the
>>> matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> 3) Section 4.4.1 - I have a slight concern regarding belo= w statement.
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>>     In the case of upstream PLR recei= ving multiple BYPASS_ASSIGNMENT
>>>
>>>     subobjects from multiple downstre= am PLRs, the decision of
>>> selecting a
>>>
>>>     bypass tunnel in the reverse dire= ction can be based on local
>>> policy,
>>>
>>>     for example, prefer link protecti= on versus node protection
>>> bypass
>>>
>>>     tunnel, or prefer the most upstre= am versus least upstream node
>>>
>>>     protection bypass tunnel.
>>>
>>> [snip]
>>>
>>> When LSRs within a bidirectional LSP employ different pol= icies, as
>>> described above, then we can result in pockets where ther= e are no
>>> protections.
>>>
>>> For example:
>>>
>>> Node A uses node protection.
>>>
>>> Node B and C use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>>         &nbs= p; ^     /
>>>
>>>         &nbs= p;  \   /
>>>
>>>         &nbs= p;   +-+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> Another example:
>>>
>>> Node A and C use node protection.
>>>
>>> Node B use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>> ^         &n= bsp;    /
>>>
>>>    \      &n= bsp;     /
>>>
>>>     +----------+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> In both cases, if there is a breakage of the link connect= ing nodes A
>>> and B, then node C receives the RSVP PATH message. If nod= e C follows
>>> procedures described in Section 6.2, then it will not fin= d a
>>> matching bypass tunnel.
>>>
>>> If I'm off track, then I apologize for the noise. If abov= e is indeed
>>> a problem, then this limitation should at least be descri= bed in the
>>> document, followed by a recommendation of all LSRs within= a
>>> bidirectional tunnel employing the same policy.
>>>
>>> It may be possible to (be brave and) address this but it = will
>>> require more procedures. I'll leave the decision and furt= her
>>> investigation to the authors.
>>>
>>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this= paragraph?
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>> [snip]
>>>
>>> I'm guessing that there should be a SHOULD ...
>>>
>>> 5) Section 6.2 - "If" and "If not" in= below text do not correspond
>>> to each other (thus a bit confusing).
>>>
>>> [snip]
>>>
>>>        - If found, che= cks whether the primary LSP traffic and
>>> signaling
>>>
>>>          are= already rerouted over the found bypass tunnel.  If not,
>>> PRR
>>>
>>>          R5 = activates FRR reroute procedures to direct traffic and
>>>
>>>          RSV= P Resv over the found bypass tunnel T2 in the
>>>
>>>          rev= erse direction.
>>>
>>> [snip]
>>>
>>> If we write above with a psuedocode, then it will be:
>>>
>>>      if (bypass tunnel found) {&= nbsp;     // "If found" is this line
>>>
>>>          che= ck if already rerouted
>>>
>>>          if = (not already rerouted) { // "If not" is this line
>>>
>>>         &nbs= p;     active FRR reroute
>>>
>>>          }
>>>
>>>      }
>>>
>>> It  might make the texts easier to read/understand i= f you can
>>> rephrase it a bit?
>>>
>>> Thanks!
>>>
>>> -Nobo
>>>
>>>
>>>
>>> _______________________________________________
>>> Teas mailing list
>>>
>>
>>--
>>
>>
>>Loa Andersson        &= nbsp;           &nbs= p;   email: loa@mail01.huawei.com
>>Senior MPLS Expert       &n= bsp;            = ;      loa@pi.nu<= /div>
>>Huawei Technologies (consultant)     phone= : +46 739 81 21 64
>>
>>_______________________________________________
>>Teas mailing list
>
 
 
--_000_D0D5B74A49E38rgandhiciscocom_-- From nobody Sat Jan 10 14:52:37 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B621A0545 for ; Sat, 10 Jan 2015 14:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 D9QFbHqz7h5Q for ; Sat, 10 Jan 2015 14:52:33 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3561A0039 for ; Sat, 10 Jan 2015 14:52:31 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id c2da1b45.0.2892842.00-2091.8095992.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 10 Jan 2015 22:52:33 +0000 (UTC) X-MXL-Hash: 54b1ad311f700a27-5fd7dc0ad0b7452cc3ef8153b437eb9fe32f1faa Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0AMqSmm001875; Sat, 10 Jan 2015 17:52:28 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0AMqJeo001836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Jan 2015 17:52:21 -0500 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 10 Jan 2015 22:52:03 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.4]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Sat, 10 Jan 2015 17:52:03 -0500 From: "BRUNGARD, DEBORAH A" To: "teas@ietf.org" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQ== Date: Sat, 10 Jan 2015 22:52:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.175.18] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C816733EF3MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NJ9iDTGg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=sC0iiI_ZkwoA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=c-pfDh31rzn_sa6GBFIA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=P4hVr3g6c_qwO11IpdIA:9 a=_W_S_7VecoQA:10 a] X-AnalysisOut: [=frz4AuCg-hUA:10 a=W--7M3zamEVwwkPy:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" Subject: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 22:52:35 -0000 --_000_F64C10EAA68C8044B33656FA214632C816733EF3MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors (WG), In preparing this document for publication, I found a few nits: - You have a lot of names on the front page, the RFC's editor's guida= nce is a max of 5 names on the front page. - Please ensure to run idnits (very verbose output), you may want to= check some of your references for updates. - Suggest to rename the heading of 4.2 to "RRO SRLG sub-object" to cl= arify. - Section 5.1, the last sentence needs a ".". - For the second paragraph, may want to consider using a separate bul= let item for the assignment of the new error subcode so as to make editing = easier. Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C816733EF3MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors (WG),
In preparing this document for publication, I found a few nits:
  • You have a lot of names on the front page, the RFC’s editor’= ;s guidance is a max of 5 names on the front page.
  • Please ensure to= run idnits (very verbose output),  you may want to check some of your= references for updates.
  • Suggest to rename the heading of 4.2 to &#= 8220;RRO SRLG sub-object” to clarify.
  • Section 5.1, the last s= entence needs a “.”.
  • For the second paragraph, may want= to consider using a separate bullet item for the assignment of the new err= or subcode so as to make editing easier.
Thanks,
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C816733EF3MISOUT7MSGUSRDE_-- From nobody Sat Jan 10 19:41:11 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8531A1AC2; Sat, 10 Jan 2015 19:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yslgeF4paUlx; Sat, 10 Jan 2015 19:41:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D427F1A1A07; Sat, 10 Jan 2015 19:41:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150111034105.19186.20202.idtracker@ietfa.amsl.com> Date: Sat, 10 Jan 2015 19:41:05 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 03:41:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-01.txt Pages : 19 Date : 2015-01-10 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 02:39:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FE1A0385 for ; Tue, 20 Jan 2015 23:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 R748SikoJ_Sn for ; Tue, 20 Jan 2015 23:30:15 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30BB1A038C for ; Tue, 20 Jan 2015 23:30:14 -0800 (PST) Received: from BN3PR0501MB1634.namprd05.prod.outlook.com (25.161.217.153) by BN3PR0501MB1506.namprd05.prod.outlook.com (25.160.117.26) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 07:30:13 +0000 Received: from BN3PR0501MB1635.namprd05.prod.outlook.com (25.161.217.154) by BN3PR0501MB1634.namprd05.prod.outlook.com (25.161.217.153) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 07:30:11 +0000 Received: from BN3PR0501MB1635.namprd05.prod.outlook.com ([25.161.217.154]) by BN3PR0501MB1635.namprd05.prod.outlook.com ([25.161.217.154]) with mapi id 15.01.0059.007; Wed, 21 Jan 2015 07:30:11 +0000 From: Cyril Margaria To: Adrian Farrel , "teas@ietf.org" Thread-Topic: AD review of draft-ietf-teas-lsp-attribute-ro Thread-Index: AdAnS4NDd8E3HP9wRBipfqBkWR+FAAN1qaEA Date: Wed, 21 Jan 2015 07:30:10 +0000 Message-ID: References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> In-Reply-To: <012001d0274b$d25f3630$771da290$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [66.129.241.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=cmargaria@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0501MB1634; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1634; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(199003)(37854004)(24454002)(189002)(92566002)(86362001)(97736003)(83506001)(66066001)(122556002)(40100003)(64706001)(46102003)(2501002)(101416001)(230783001)(36756003)(87936001)(2656002)(2900100001)(2950100001)(19580395003)(19580405001)(99286002)(76176999)(54356999)(68736005)(105586002)(50986999)(102836002)(106356001)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1634; H:BN3PR0501MB1635.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2015 07:30:10.7095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1634 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1506; X-OriginatorOrg: juniper.net Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 02:39:04 -0800 Cc: "draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org" , "draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org" , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 07:30:18 -0000 Hi,=20 Thanks for your careful review, Please see inline. WG feedback is welcomed. On 03.01.15 06:52, "Adrian Farrel" wrote: >Hi authors, > >Thanks for this document, the first from TEAS to reach me for >publication. I found it to be a simple and clear read. The IANA section >is clear and well-written. > >I have done my usual AD review with the intent to catch any remaining >issues before issuing IETF last call. > >I think my first three points need discussion with the working group. >The remaining points are relatively small. > >While I wait for your discussion or a new revision, I'll put the draft >into "Revised I-D Needed" state. > >Thanks for your work, >Adrian > >--- > >Section 2.3 needs to describe the processing when an ERO Hop Attributes >subobject is encountered after a loose hop subobject or a strict hop >that is an abstract node? > >- Is it valid? >- Is it assumed to apply to all hops in that loose hop or abstract node? >- Or in the case of a loose hop, does it just apply to the named hop > itself? >- What about if the preceding subobject is an interface identifier or a > label? > >I wonder whether reference to 4990 would help at all. Following RFC4990, it depends. In the context of draft-ietf-teas-rsvp-te-li-lb, a loopback after a loose hop, could be rejected. This should not apply to a label or interface In the context of draft-ietf-ccamp-wson-signaling-09, a ResourceBlockInfo should target an explicit Hop, but the WavelengthSelection could appear after an abstract node or loose hop. Future Attributes TLV may apply to interfaces or labels. I think its up to the document defining the TLV to scope it. For instance the following text could address that: Depending on the scope of thea specific Hop attribute TLV, the defining document SHOULD describe after which kind of hop they are valid, for instance by describing rules similar to [RFC4990] section 6.1. For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV to explicit nodes, precluding link ids): The Attribute Flags TLV with Loopback Attribute Flag set MUST be present after an explicit Hop addressing an TE Router ID identifying a specific node or a Link ID identifying an incoming TE link. it MUST NOT be present after a loose, abstract node, Link ID identifying an outgoing TE link, Component Interface ID or Label. For draft-ietf-ccamp-wson-signaling-09, this could be (restricting the ResourceBlockInfo to explicit nodes): The WSON Processing HOP Attribute TLV with ResourceBlockInfo MUST be present after an explicit Hop addressing an TE Router ID identifying a specific node or a Link ID identifying an incoming TE link. it MUST NOT be present after a loose, abstract node, Link ID identifying an outgoing TE link, Component Interface ID or Label. The WSON Processing HOP Attribute TLV with WavelengthSelection only MUST be present after an explicit Hop addressing an TE Router ID identifying a specific node, a Link ID identifying an incoming TE link, loose hop, abstract node, Link ID identifying an outgoing TE lin or Component Interface ID. it MUST NOT be present after a Label. The WavelengthSelection may apply starting at an abstract node, but not after a label (as no selection is possible) > >Note that 3.2 seems to handle all the options for use in the RRO. > >--- > >3.2.1 has > > All such =20 > subobjects MUST be forwarded unmodified by transit LSRs. > >That is, of course, the general rule, but I assume that there are >exceptions. > >For example, an ASBR may choose to prune the information that is >forwarded in an RRO. Similarly, the UNI-N may strip information. > >I think the point would be that "If a node forwards an RRO subobject >for a specific hop, it MUST forward any associated HOP Attributes >subobjects." > >But even this may be too restrictive for a border node that wants to >report the chosen path but not expose how the internals of its network >are operated. In this case it may want to strip HOP Attributes >subobjects from the RRO or even modify them to mask information. > >Can you add some clarification about all of this? Absolutely, for instance changing the MUST in SHOULD, and adding the following text: "It is noted that a node (e.g. a domain edge node) may edit the RRO to prune/modify the RRO, including the RRO Hop Attribute subobject before forwarding due to confidentiality policy or other reasons (for instance RRO size reduction)." > >--- > >I think section 5 is a little optimistic. You are introducing a new >mechanism for the control of the behavior on certain nodes on the path >of the LSP. Since the control of those nodes may impact the behavior of >other LSPs passing the node, some care is needed. For example, setting >optical power levels for one lambda can interfere with the signals on >other lambdas. Thus, and in general, you have a mechanism that takes >control away from the node itself and puts it in the hand of the node >that signaled the LSP. This opens up three security possibilities: >1. Simple errors in the attributes of an LSP may inadvertently impact > existing LSPs while still allowing this LSP to be set up. >2. A malign ingress may signal an LSP down a path and with attributes > chosen to damage other LSPs from other ingresses. >3. An attacked Path message may result in damage to other LSPs. > >The third of these is mitigated somewhat by existing RSVP-TE security >mechanisms. The first two (and the third in the case of a subverted >node) can only be mitigated by allowing policy to be applied at a node >that implements the HOP Attributes it receives in an ERO. A node must be >allowed to determine that satisfy the attributes would be inadvisable or >against local policy even if practically possible. In these cases the >node has a choice to either reject the Path message (but a new error >code might be helpful) or to modify the requested attribute (but in this >case it might be required to report exactly what it has done, presumably >in the RRO). I agree in general, the existing text refer to the hop attributes as =B3functional preferences=B2, as any other RSVP object, this is to be considered as =B3external input=B2, so subject to policy and sanity check. The document does not define how the TLV have to be applied (Just that the content must be processed). The aspect of targetting other LSP is, I think, especially valid for WSON, but less applicable for MPLS-TP. The same consideration also apply for explicit label control. OLD: "As any RSVP-TE signaling request, the procedures defined in this document permit the transfer and reporting of functional preferences on specific node.=B2 NEW: "As any RSVP-TE signaling request, the procedures defined in this document permit the transfer and reporting of functional preferences on specific node. The mechanism added in this document does allow more control of LSP attributes at a given node. As other inputs, a node should check the Hop Attributes against his policies and admission procedures. A node may reject the message using existing RSVP error code like "Policy Control Failure" or "Admission Control Failure". The node may also, depending on the specific TLV procedures, modify the requested attribute. "=20 I think that Attribute modification is TLV-dependant and should be specified in the defining documents. > >=3D=3D=3D > >Please don't "propose". You intend this document to be published as an >RFC, so you should "define". Agree, >--- > >3.1 has > > Attributes TLVs The processed or addition HOP Attributes, using the > format defined in Section 2.2 . > >Trying to parse this, I think you mean s/addition/additional/ Agree, > >--- > >3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder what >the exception cases are: under what circumstances MAY an implementation >vary from these rules? If a specific attribute/document allows it. Wouldn=B9t a MUST in that case be too restrictive for those documents? Would the following text clarify in which case this may be allowed? A node MAY use the RRO Hop Attribute to report a LSP Attribute signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the following conditions are met : Rhe Attribute and its corresponding flag is allowed on both the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes subobject. The document defining this Attribute specify this specific behavior. > >--- > >In section 4.2, do you want to add a request to IANA to use the same >value as assigned in 4.1? Agree. From nobody Wed Jan 21 03:57:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442E11A1A22; Wed, 21 Jan 2015 03:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 KjYjmYEmkMbF; Wed, 21 Jan 2015 03:57:43 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58411A1A1E; Wed, 21 Jan 2015 03:57:42 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LBveuw013271; Wed, 21 Jan 2015 11:57:40 GMT Received: from 950129200 (089144210022.atnat0019.highway.a1.net [89.144.210.22]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LBvb84013235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 11:57:38 GMT From: "Adrian Farrel" To: "'Cyril Margaria'" , References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> In-Reply-To: Date: Wed, 21 Jan 2015 11:57:37 -0000 Message-ID: <011b01d03571$7526d480$5f747d80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNJKbqcA8ICrxY/nQ0vdspVCXFtAG4lZZam8LQ7AA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21270.001 X-TM-AS-Result: No--22.294-10.0-31-10 X-imss-scan-details: No--22.294-10.0-31-10 X-TMASE-MatchedRID: Ync95tbzDRmnykMun0J1wtxajlW+zwxCC/ExpXrHizwJW4Re2U2py+50 k+nSYSmWO4Z0ZkXCjJsUPsM54RzshHYIQoHEix+qdrpCZsJVIIUpWss5kPUFdGu9/l5WAy7sbOh vQwxZCUumUhnCmPhVLUlKUqmaZWPdzsxad8fKloYzSlmIs9AhOtEA4SsNDgaiXudxyY/AL0eXNa gpKKGTEzmrSBe3bBipItB1q1kmkIKbdVs/uMg2/8H0JgP/bKWSQa2sDHLkQ040QmmUihPzrJ8zj Z45FG+UwOalMNNoWHYYkIWWLQ+ruev/j3sV8W9mW7gz/Gbgpl4/W/kEeVcLFGjSAumzejoRDgvn ApkxBAVSRo6Tk1CHbLtnawFLb7obvYmC3IHzHcj/VoEOchXiKVXKDhjPZTukMKZRiezcUtMgRPl rGC5FrzzIYciYTdEA3KCE1AIrmzWH6FJxCilEmWbzlCg24oq+h+w9Wz/xXDprEoFtNYg0C4ARql 3UMZ6bVgi2vEnHdgKGDG1lR3xKVq+2LFpqaFp51yMJs9mBCcUvfgjwim9BwsUdzAovpQT/eu5z4 syzGYYu6BdQaUaE9nkNrWD+KBWtoayr11+eKrlRKfej56hSbJsqkCVjbLpJAuVirUrNCL+g0ehM cZ850tJpCbWqQKk2C1MkYihD/gEKT+RHLhCkHMqXjImgj58becvjbu/xDjr3qGsw1oZ+zxwz72z DzvkOCMe3Br715Je4Clh+0goxykq+i9GrWzgshsE+u3nnCfAk227IvqakhftHa1P9/19Uo8WMkQ Wv6iXhWDPiI8D3842j49Ftap9EkGUtrowrXLg= Archived-At: Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org, ccamp@ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 11:57:46 -0000 Hi Cyril, Thanks for engaging. [CCAMP - note just one point wrt draft-ietf-ccamp-wson-signaling] > >Section 2.3 needs to describe the processing when an ERO Hop = Attributes > >subobject is encountered after a loose hop subobject or a strict hop > >that is an abstract node? > > > >- Is it valid? > >- Is it assumed to apply to all hops in that loose hop or abstract = node? > >- Or in the case of a loose hop, does it just apply to the named hop > > itself? > >- What about if the preceding subobject is an interface identifier or = a > > label? > > > >I wonder whether reference to 4990 would help at all. >=20 > Following RFC4990, it depends. > In the context of draft-ietf-teas-rsvp-te-li-lb, a loopback after a = loose > hop, could be rejected. This should not apply to a label or interface > In the context of draft-ietf-ccamp-wson-signaling-09, a = ResourceBlockInfo > should target an explicit Hop, but the WavelengthSelection could = appear > after an abstract node or loose hop. >=20 > Future Attributes TLV may apply to interfaces or labels. I think its = up to > the document defining the TLV to scope it. > For instance the following text could address that: > Depending on the scope of thea specific Hop attribute TLV, the = defining > document SHOULD describe after which kind of hop they are valid, for > instance by describing rules similar to [RFC4990] section 6.1. OK. This is clear. Thanks. I think *this* I-D needs to make it clear what the expectations are: 1. The sub-object is allowed at any point in the ERO 2. The document that specifies a TLV for the sub-object must make it clear where in an ERO a sub-object containing that TLV is allowed and not allowed. That should be an easy edit for you. > For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV = to > explicit nodes, precluding link ids): > The Attribute Flags TLV with Loopback Attribute Flag set MUST be = present > after an explicit Hop addressing an TE Router ID identifying a = specific > node or a Link ID identifying an incoming TE link. it MUST NOT be = present > after a loose, abstract node, Link ID identifying an outgoing TE = link, > Component Interface ID or Label. Ah, joy! Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb. I've made a note in the data tracker and marked that I-D as needing a = new revision. > For draft-ietf-ccamp-wson-signaling-09, this could be (restricting the > ResourceBlockInfo to explicit nodes): >=20 > The WSON Processing HOP Attribute TLV with ResourceBlockInfo MUST be > present after an explicit Hop addressing an TE Router ID identifying a > specific node or a Link ID identifying an incoming TE link. it MUST = NOT be > present after a loose, abstract node, Link ID identifying an outgoing = TE > link, Component Interface ID or Label. >=20 > The WSON Processing HOP Attribute TLV with WavelengthSelection only = MUST > be present after an explicit Hop addressing an TE Router ID = identifying a > specific node, a Link ID identifying an incoming TE link, loose hop, > abstract node, Link ID identifying an outgoing TE lin or Component > Interface ID. it MUST NOT be present after a Label. >=20 > The WavelengthSelection may apply starting at an abstract node, but = not > after a label (as no selection is possible) Phew, this I-D is still pending my review. I'll capture that as I process it. Thanks for doing the work of crafting text. [I added CCAMP to the recipients of this email so they can see this = point] =20 > >3.2.1 has > > > > All such > > subobjects MUST be forwarded unmodified by transit LSRs. > > > >That is, of course, the general rule, but I assume that there are > >exceptions. > > > >For example, an ASBR may choose to prune the information that is > >forwarded in an RRO. Similarly, the UNI-N may strip information. > > > >I think the point would be that "If a node forwards an RRO subobject > >for a specific hop, it MUST forward any associated HOP Attributes > >subobjects." > > > >But even this may be too restrictive for a border node that wants to > >report the chosen path but not expose how the internals of its = network > >are operated. In this case it may want to strip HOP Attributes > >subobjects from the RRO or even modify them to mask information. > > > >Can you add some clarification about all of this? >=20 > Absolutely, for instance changing the MUST in SHOULD, and adding the > following text: >=20 > "It is noted that a node (e.g. a domain edge node) may edit the RRO to > prune/modify the RRO, including the RRO Hop Attribute subobject before > forwarding due to confidentiality policy or other reasons (for = instance > RRO size reduction)." Perfect. =20 > >I think section 5 is a little optimistic. You are introducing a new > >mechanism for the control of the behavior on certain nodes on the = path > >of the LSP. Since the control of those nodes may impact the behavior = of > >other LSPs passing the node, some care is needed. For example, = setting > >optical power levels for one lambda can interfere with the signals on > >other lambdas. Thus, and in general, you have a mechanism that takes > >control away from the node itself and puts it in the hand of the node > >that signaled the LSP. This opens up three security possibilities: > >1. Simple errors in the attributes of an LSP may inadvertently impact > > existing LSPs while still allowing this LSP to be set up. > >2. A malign ingress may signal an LSP down a path and with attributes > > chosen to damage other LSPs from other ingresses. > >3. An attacked Path message may result in damage to other LSPs. > > > >The third of these is mitigated somewhat by existing RSVP-TE security > >mechanisms. The first two (and the third in the case of a subverted > >node) can only be mitigated by allowing policy to be applied at a = node > >that implements the HOP Attributes it receives in an ERO. A node must = be > >allowed to determine that satisfy the attributes would be inadvisable = or > >against local policy even if practically possible. In these cases the > >node has a choice to either reject the Path message (but a new error > >code might be helpful) or to modify the requested attribute (but in = this > >case it might be required to report exactly what it has done, = presumably > >in the RRO). >=20 > I agree in general, the existing text refer to the hop attributes as > =B3functional preferences=B2, as any other RSVP object, this is to be > considered as =B3external input=B2, so subject to policy and sanity = check. > The document does not define how the TLV have to be applied (Just that = the > content must be processed). The aspect of targetting other LSP is, I > think, especially valid for WSON, but less applicable for MPLS-TP. > The same consideration also apply for explicit label control. >=20 > OLD: > "As any RSVP-TE signaling request, the procedures defined in this > document permit the transfer and reporting of functional = preferences > on specific node.=B2 >=20 > NEW: > "As any RSVP-TE signaling request, the procedures defined in this > document permit the transfer and reporting of functional = preferences > on specific node. > The mechanism added in this document does allow more control of LSP > attributes at a given node. As other inputs, a node should check the = Hop > Attributes against his policies and admission procedures. > A node may reject the message using existing RSVP error code like = "Policy > Control Failure" or "Admission Control Failure". The node may also, > depending on the specific TLV procedures, modify the requested = attribute. > " Perfect. > I think that Attribute modification is TLV-dependant and should be > specified in the defining documents. You should probably also include a statement of this so that people are = reminded to do exactly that. > >3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder > > what the exception cases are: under what circumstances MAY an > > implementation vary from these rules? >=20 > If a specific attribute/document allows it. Wouldn=B9t a MUST in that = case > be too restrictive for those documents? >=20 > Would the following text clarify in which case this may be allowed? >=20 > A node MAY use the RRO Hop Attribute to report a LSP Attribute > signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the > following conditions are met : >=20 > Rhe Attribute and its corresponding flag is allowed on both the > LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes > subobject. >=20 > The document defining this Attribute specify this specific > behavior. Like it. s/Rhe/The/ Thanks, Please post the updated version. Adrian From nobody Wed Jan 21 11:17:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2111A802D for ; Wed, 21 Jan 2015 11:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] autolearn=no 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 m9r2LuNhpOSq for ; Wed, 21 Jan 2015 11:17:14 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85941A8035 for ; Wed, 21 Jan 2015 11:17:10 -0800 (PST) Received: from localhost ([::1]:52596) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YE0m4-0005eY-H0; Wed, 21 Jan 2015 22:17:08 +0300 Message-ID: <54BFFB31.6050102@labn.net> Date: Wed, 21 Jan 2015 14:17:05 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Cyril Margaria' , teas@ietf.org References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> <011b01d03571$7526d480$5f747d80$@olddog.co.uk> In-Reply-To: <011b01d03571$7526d480$5f747d80$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:17:16 -0000 [ccamp dropped response doesn't concern the WSON draft] On 1/21/2015 6:57 AM, Adrian Farrel wrote: >> For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV to >> > explicit nodes, precluding link ids): >> > The Attribute Flags TLV with Loopback Attribute Flag set MUST be present >> > after an explicit Hop addressing an TE Router ID identifying a specific >> > node or a Link ID identifying an incoming TE link. it MUST NOT be present >> > after a loose, abstract node, Link ID identifying an outgoing TE link, >> > Component Interface ID or Label. > Ah, joy! > Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb. > I've made a note in the data tracker and marked that I-D as needing a new > revision. > I think this phrasing is too restrictive as it may be possible to put some of the identified items into loopback in some technologies, e.g., an output interface. How about: after: The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to address the loopback request to the particular node. add: The ingress MUST ensure that the desired loopback mode is strictly identified in the ERO. and OLD: If the bit is set, the node SHOULD try to put the LSP into loopback mode. NEW If the bit is set, the node MUST check that the desired loopback is strictly identified by verifying that the L bit is set to 0 in both the ERO Hop Attributes subobject and the prior subobject. The prior subobject MUST also be checked to ensure that it provides strict identification. Currently, the type value MUST be verified to be less than 32, and for type values 1 and 2 the prefix length MUST be 32 and 128 respectively. If the desired loopback is not strictly identified the request MUST be ignored and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. Otherwise, the node SHOULD try to put the LSP into loopback mode. Lou From nobody Wed Jan 21 12:13:34 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B71A87B0 for ; Wed, 21 Jan 2015 12:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o-Cw-o6ODjMD for ; Wed, 21 Jan 2015 12:13: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 96A811A87A7 for ; Wed, 21 Jan 2015 12:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11622; q=dns/txt; s=iport; t=1421871204; x=1423080804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rwipaNV6YNxmyn1qAMeZUdGwOXklgRgHFf+ShviB9eI=; b=HncStER71uV6KR7rOtchIo5zBBN4W7Ux1L4PdQCkd/z4CIihTuJeAX7v +hi9XIm4q7AGnfafjiP7UhIb2edTOUACe35P32b26TsXl6G6lFXizkXQK T0UtOFrGVVrL6HFNR2BmuxU2P+mWYuGGGXfi4yVO3SHQ0ODbYXxk/Dv+H Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAOUHwFStJV2a/2dsb2JhbABbgkNDUlzMCgKBKEMBAQEBAX2EDQEBBC1MEAIBCCIkMiUBAQQBDQ2IJNJoAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49IMQeDFoETBY5ZiiuCfIpdgz0ig26CNH4BAQE X-IronPort-AV: E=Sophos;i="5.09,444,1418083200"; d="scan'208,217";a="386376523" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jan 2015 20:13:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0LKDNWu021712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 20:13:23 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.219]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 14:13:23 -0600 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , "teas@ietf.org" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4Cg Date: Wed, 21 Jan 2015 20:13:23 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.90] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC289F2E58xmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" , "Matt Hartley \(mhartley\)" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 20:13:27 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC289F2E58xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deborah, Apologies for the late response - this one got buried :) Thanks for the comments. Are you OK with us keeping them on the to-do list = and addressing them whenever we do a new revision of the doc? Cheers Matt Authors (WG), In preparing this document for publication, I found a few nits: * You have a lot of names on the front page, the RFC's editor's gui= dance is a max of 5 names on the front page. * Please ensure to run idnits (very verbose output), you may want = to check some of your references for updates. * Suggest to rename the heading of 4.2 to "RRO SRLG sub-object" to = clarify. * Section 5.1, the last sentence needs a ".". * For the second paragraph, may want to consider using a separate b= ullet item for the assignment of the new error subcode so as to make editin= g easier. Thanks, Deborah --_000_9D50FCE7413E3D4EA5E42331115FB5BC289F2E58xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deborah,<= /span>

 

Apologies for the la= te response – this one got buried :)

 

Thanks for the comme= nts. Are you OK with us keeping them on the to-do list and addressing them = whenever we do a new revision of the doc?

 

Cheers

 

Matt

 

 

Authors (WG),

In preparing this document for publicat= ion, I found a few nits:

·         You have a lot of names on the = front page, the RFC’s editor’s guidance is a max of 5 names on = the front page.

·         Please ensure to run idnits (ve= ry verbose output),  you may want to check some of your references for= updates.

·         Suggest to rename the heading o= f 4.2 to “RRO SRLG sub-object” to clarify.

·         Section 5.1, the last sentence = needs a “.”.

·         For the second paragraph, may w= ant to consider using a separate bullet item for the assignment of the new = error subcode so as to make editing easier.

Thanks,

Deborah

 

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC289F2E58xmbrcdx03ciscoc_-- From nobody Wed Jan 21 13:10:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCBF1A8889 for ; Wed, 21 Jan 2015 13:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 hV1-sCcLdJd4 for ; Wed, 21 Jan 2015 13:10:06 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6371A8888 for ; Wed, 21 Jan 2015 13:10:05 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id da510c45.2aedf3611940.2525285.00-2461.7071989.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:10:05 +0000 (UTC) X-MXL-Hash: 54c015ad2ff50067-dd8fbeba0890bd54e6669bc00304f00134948771 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 4a510c45.0.2525135.00-1944.7071509.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:10:00 +0000 (UTC) X-MXL-Hash: 54c015a8369fc304-ff22fdbf8a5619e561da74da0c50daff92b727e6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LL9tDp007509; Wed, 21 Jan 2015 16:09:56 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LL9fY6007309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jan 2015 16:09:49 -0500 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 21 Jan 2015 21:09:19 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.33]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 16:09:19 -0500 From: "BRUNGARD, DEBORAH A" To: "Matt Hartley (mhartley)" , "teas@ietf.org" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4CgAAHrRcA= Date: Wed, 21 Jan 2015 21:09:18 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.179] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B4DC572MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BpYqN/r5 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=Vme8EfoV89kA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=H5neHVUe80ZTaBFrqioA:9 a=CjuIK1q_8ugA:10 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=XYDIZ2TCXri9BitIYtcA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=5P5w5zK_2NxD2QUS:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:10:09 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B4DC572MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt, Are you planning to do another update? Lou and I were thinking that this wa= s ready to submit for publication? Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 3:13 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhar= tley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, Apologies for the late response - this one got buried :) Thanks for the comments. Are you OK with us keeping them on the to-do list = and addressing them whenever we do a new revision of the doc? Cheers Matt Authors (WG), In preparing this document for publication, I found a few nits: * You have a lot of names on the front page, the RFC's editor's gui= dance is a max of 5 names on the front page. * Please ensure to run idnits (very verbose output), you may want = to check some of your references for updates. * Suggest to rename the heading of 4.2 to "RRO SRLG sub-object" to = clarify. * Section 5.1, the last sentence needs a ".". * For the second paragraph, may want to consider using a separate b= ullet item for the assignment of the new error subcode so as to make editin= g easier. Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C83B4DC572MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matt,

 <= /p>

Are you planning to do an= other update? Lou and I were thinking that this was ready to submit for pub= lication?

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisco.com]
Sent: Wednesday, January 21, 2015 3:13 PM
To: BRUNGARD, DEBORAH A; teas@ietf.org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

Apologies for the la= te response – this one got buried :)

 

Thanks for the comme= nts. Are you OK with us keeping them on the to-do list and addressing them = whenever we do a new revision of the doc?

 

Cheers

 

Matt

 

 

Authors (WG),

In preparing this document for publicat= ion, I found a few nits:

·         You have a lot of names on the = front page, the RFC’s editor’s guidance is a max of 5 names on = the front page.

·         Please ensure to run idnits (ve= ry verbose output),  you may want to check some of your references for= updates.

·         Suggest to rename the heading o= f 4.2 to “RRO SRLG sub-object” to clarify.

·         Section 5.1, the last sentence = needs a “.”.

·         For the second paragraph, may w= ant to consider using a separate bullet item for the assignment of the new = error subcode so as to make editing easier.

Thanks,

Deborah

 

 

--_000_F64C10EAA68C8044B33656FA214632C83B4DC572MISOUT7MSGUSRDE_-- From nobody Wed Jan 21 13:17:56 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0C1A888B for ; Wed, 21 Jan 2015 13:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xenyBbz3RbF4 for ; Wed, 21 Jan 2015 13:17:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3091A888A for ; Wed, 21 Jan 2015 13:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16906; q=dns/txt; s=iport; t=1421875073; x=1423084673; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W39PvX6I5XioPwzChqKjruRmQ4WC5bvtAzvJhFDy5Hs=; b=MRQp1TCCDXvpu27MrovVETUvV61912wSMjRsjcPXru+b1VbHsYhzoSX1 7fNZo6zuQKlNgeHXFO8KkYkKcSnIpMYZtDyIvFUk+q6GoR6qpwZSO2iv2 tcZDJAW6YofqTosNEpf4YyygtAh1+UJoUFFURgVQn8YtVUCQ9N3UgNgpk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGkWwFStJV2R/2dsb2JhbABbgkNDUlgEzAwCgShDAQEBAQF9hAwBAQEELUcFEAIBCBEEAQELHQcyFAkIAQEEAQ0FCBeIDdJ9AQEBAQEBAQEBAQEBAQEBAQEBAQEBF49IMQYBgxaBEwWOWYorgnyHbIJxgz0ig25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.09,444,1418083200"; d="scan'208,217";a="389472907" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 21 Jan 2015 21:17:52 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0LLHpvw007231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 21:17:51 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.219]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 15:17:50 -0600 From: "Matt Hartley (mhartley)" To: "BRUNGARD, DEBORAH A" , "teas@ietf.org" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4CgAAHrRcAAAFXVAA== Date: Wed, 21 Jan 2015 21:17:50 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC289F30F6@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.90] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC289F30F6xmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" , "Matt Hartley \(mhartley\)" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:17:54 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC289F30F6xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deborah, We weren't planning on it... I'm just working on the assumption that we won= 't get through the AD and IESG reviews without any comments at all, so ther= e will be another revision at some stage and we could address your comments= then. Does that sound reasonable? Cheers Matt Hi Matt, Are you planning to do another update? Lou and I were thinking that this wa= s ready to submit for publication? Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 3:13 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhartley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, Apologies for the late response - this one got buried :) Thanks for the comments. Are you OK with us keeping them on the to-do list = and addressing them whenever we do a new revision of the doc? Cheers Matt Authors (WG), In preparing this document for publication, I found a few nits: * You have a lot of names on the front page, the RFC's editor's gui= dance is a max of 5 names on the front page. * Please ensure to run idnits (very verbose output), you may want = to check some of your references for updates. * Suggest to rename the heading of 4.2 to "RRO SRLG sub-object" to = clarify. * Section 5.1, the last sentence needs a ".". * For the second paragraph, may want to consider using a separate b= ullet item for the assignment of the new error subcode so as to make editin= g easier. Thanks, Deborah --_000_9D50FCE7413E3D4EA5E42331115FB5BC289F30F6xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deborah,<= /span>

 

We weren’t pla= nning on it… I’m just working on the assumption that we wonR= 17;t get through the AD and IESG reviews without any comments at all, so th= ere will be another revision at some stage and we could address your comments then.= Does that sound reasonable?

 

Cheers

 

Matt

 

Hi Matt,

 <= /p>

Are you planning to do an= other update? Lou and I were thinking that this was ready to submit for pub= lication?

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisc= o.com]
Sent: Wednesday, January 21, 2015 3:13 PM
To: BRUNGARD, DEBORAH A; teas@ietf.= org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

Apologies for the la= te response – this one got buried :)

 

Thanks for the comme= nts. Are you OK with us keeping them on the to-do list and addressing them = whenever we do a new revision of the doc?

 

Cheers

 

Matt

 

 

Authors (WG),

In preparing this document for publicat= ion, I found a few nits:

·         You have a lot of names on the = front page, the RFC’s editor’s guidance is a max of 5 names on = the front page.

·         Please ensure to run idnits (ve= ry verbose output),  you may want to check some of your references for= updates.

·         Suggest to rename the heading o= f 4.2 to “RRO SRLG sub-object” to clarify.

·         Section 5.1, the last sentence = needs a “.”.

·         For the second paragraph, may w= ant to consider using a separate bullet item for the assignment of the new = error subcode so as to make editing easier.

Thanks,

Deborah

 

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC289F30F6xmbrcdx03ciscoc_-- From nobody Wed Jan 21 13:25:28 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03481A887E for ; Wed, 21 Jan 2015 13:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Ez98XubuNBw9 for ; Wed, 21 Jan 2015 13:25:23 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09951A887A for ; Wed, 21 Jan 2015 13:25:22 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 24910c45.2b554828c940.407116.00-2457.1160509.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:25:22 +0000 (UTC) X-MXL-Hash: 54c019423e5e4275-66f2a148221d9f8daac70bc88410df377d1515be Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 14910c45.0.407105.00-2300.1160433.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:25:21 +0000 (UTC) X-MXL-Hash: 54c019410bd38c45-09d6063eef6d6379f00577a3507c263988bcc9dc Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LLPKpG023094; Wed, 21 Jan 2015 16:25:21 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LLPFGv022940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jan 2015 16:25:16 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 21 Jan 2015 21:24:59 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.33]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 16:24:59 -0500 From: "BRUNGARD, DEBORAH A" To: "Matt Hartley (mhartley)" , "teas@ietf.org" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4CgAAHrRcAAAFXVAAAAGkVw Date: Wed, 21 Jan 2015 21:24:58 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC289F30F6@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC289F30F6@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.179] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B4DC5A0MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=L/KqtZv8 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=Vme8EfoV89kA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=d19fbtIkVMgD0U60d14A:9 a=CjuIK1q_8ugA:10 a=YqkQ1-72] X-AnalysisOut: [jw9hRKC8:21 a=PBJFDi1FzjVKI1vw:21 a=yMhMjlubAAAA:8 a=SSmOF] X-AnalysisOut: [EACAAAA:8 a=VDH51rXn2IfhOZvvrdQA:9 a=gKO2Hq4RSVkA:10 a=UiC] X-AnalysisOut: [Q7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=f1Khok-] X-AnalysisOut: [MGYO5TiTL:21 a=vyYhYNw5aF3cz1bY:21 a=mygDgiuPruEfaeXx:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:25:27 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B4DC5A0MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt, You will need to clean up the first page and check the references - run nit= s and cleanup - before we can submit. Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 4:18 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhar= tley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, We weren't planning on it... I'm just working on the assumption that we won= 't get through the AD and IESG reviews without any comments at all, so ther= e will be another revision at some stage and we could address your comments= then. Does that sound reasonable? Cheers Matt Hi Matt, Are you planning to do another update? Lou and I were thinking that this wa= s ready to submit for publication? Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 3:13 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhartley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, Apologies for the late response - this one got buried :) Thanks for the comments. Are you OK with us keeping them on the to-do list = and addressing them whenever we do a new revision of the doc? Cheers Matt Authors (WG), In preparing this document for publication, I found a few nits: * You have a lot of names on the front page, the RFC's editor's gui= dance is a max of 5 names on the front page. * Please ensure to run idnits (very verbose output), you may want = to check some of your references for updates. * Suggest to rename the heading of 4.2 to "RRO SRLG sub-object" to = clarify. * Section 5.1, the last sentence needs a ".". * For the second paragraph, may want to consider using a separate b= ullet item for the assignment of the new error subcode so as to make editin= g easier. Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C83B4DC5A0MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matt,

 <= /p>

You will need to clean up= the first page and check the references – run nits and cleanup ̵= 1; before we can submit.

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisco.com]
Sent: Wednesday, January 21, 2015 4:18 PM
To: BRUNGARD, DEBORAH A; teas@ietf.org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

We weren’t pla= nning on it… I’m just working on the assumption that we wonR= 17;t get through the AD and IESG reviews without any comments at all, so th= ere will be another revision at some stage and we could address your comments then.= Does that sound reasonable?

 

Cheers

 

Matt

 

Hi Matt,

 <= /p>

Are you planning to do an= other update? Lou and I were thinking that this was ready to submit for pub= lication?

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisc= o.com]
Sent: Wednesday, January 21, 2015 3:13 PM
To: BRUNGARD, DEBORAH A; teas@ietf.= org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

Apologies for the la= te response – this one got buried :)

 

Thanks for the comme= nts. Are you OK with us keeping them on the to-do list and addressing them = whenever we do a new revision of the doc?

 

Cheers

 

Matt

 

 

Authors (WG),

In preparing this document for publicat= ion, I found a few nits:

·         You have a lot of names on the = front page, the RFC’s editor’s guidance is a max of 5 names on = the front page.

·         Please ensure to run idnits (ve= ry verbose output),  you may want to check some of your references for= updates.

·         Suggest to rename the heading o= f 4.2 to “RRO SRLG sub-object” to clarify.

·         Section 5.1, the last sentence = needs a “.”.

·         For the second paragraph, may w= ant to consider using a separate bullet item for the assignment of the new = error subcode so as to make editing easier.

Thanks,

Deborah

 

 

--_000_F64C10EAA68C8044B33656FA214632C83B4DC5A0MISOUT7MSGUSRDE_-- From nobody Wed Jan 21 13:44:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05041A88FE for ; Wed, 21 Jan 2015 13:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8sAhJM5FlS2r for ; Wed, 21 Jan 2015 13:44:14 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C611A0018 for ; Wed, 21 Jan 2015 13:44:12 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 62AB7E0154; Wed, 21 Jan 2015 22:44:09 +0100 (CET) Received: from ESTGVMSP114.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 47958E014B; Wed, 21 Jan 2015 22:44:09 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.55) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 21 Jan 2015 22:44:08 +0100 Received: from AM2PR06MB0657.eurprd06.prod.outlook.com (25.161.18.151) by AM2PR06MB0660.eurprd06.prod.outlook.com (25.161.18.154) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 21:43:58 +0000 Received: from AM2PR06MB0657.eurprd06.prod.outlook.com ([25.161.18.151]) by AM2PR06MB0657.eurprd06.prod.outlook.com ([25.161.18.151]) with mapi id 15.01.0059.007; Wed, 21 Jan 2015 21:43:58 +0000 From: OSCAR GONZALEZ DE DIOS To: "BRUNGARD, DEBORAH A" Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4CgAAHrRcAAAFXVAAAAGkVwAADcb8o= Date: Wed, 21 Jan 2015 21:43:57 +0000 Message-ID: <90E64A62-BD07-4FB3-B040-4EADE1159B52@telefonica.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC289F30F6@xmb-rcd-x03.cisco.com>, In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [190.216.136.20] authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.gonzalezdedios@telefonica.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AM2PR06MB0660; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:AM2PR06MB0660; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(43544003)(199003)(479174004)(51914003)(164054003)(189002)(377454003)(68736005)(102836002)(110136001)(97736003)(82746002)(19625215002)(106356001)(105586002)(101416001)(19580395003)(19580405001)(92566002)(93886004)(83716003)(46102003)(33656002)(230783001)(2656002)(86362001)(16236675004)(36756003)(40100003)(64706001)(66066001)(122556002)(87936001)(15187005004)(50986999)(2950100001)(77156002)(54356999)(76176999)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR06MB0660; H:AM2PR06MB0657.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_90E64A62BD074FB3B0404EADE1159B52telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2015 21:43:57.7864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR06MB0660 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "Matt Hartley \(mhartley\)" , "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" , "teas@ietf.org" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:44:19 -0000 --_000_90E64A62BD074FB3B0404EADE1159B52telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable HI Deborah, Matt, I can take care of the clean-up by the end of the week (I am in business tr= ip now). However, there is one thing I do not have a solution yet.. One of the comme= nts is about the number of authors.. There are 6 now... And the recommendat= ion is 5... Is 5 a recommendation or a MUST? Could we live with 6? Oscar Enviado desde mi iPhone El 21/1/2015, a las 16:25, BRUNGARD, DEBORAH A > escribi=C3=B3: Hi Matt, You will need to clean up the first page and check the references =E2=80=93= run nits and cleanup =E2=80=93 before we can submit. Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 4:18 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhartley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, We weren=E2=80=99t planning on it=E2=80=A6 I=E2=80=99m just working on the = assumption that we won=E2=80=99t get through the AD and IESG reviews withou= t any comments at all, so there will be another revision at some stage and = we could address your comments then. Does that sound reasonable? Cheers Matt Hi Matt, Are you planning to do another update? Lou and I were thinking that this wa= s ready to submit for publication? Thanks, Deborah From: Matt Hartley (mhartley) [mailto:mhartley@cisco.com] Sent: Wednesday, January 21, 2015 3:13 PM To: BRUNGARD, DEBORAH A; teas@ietf.org Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartley (mhartley) Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect Deborah, Apologies for the late response =E2=80=93 this one got buried :) Thanks for the comments. Are you OK with us keeping them on the to-do list = and addressing them whenever we do a new revision of the doc? Cheers Matt Authors (WG), In preparing this document for publication, I found a few nits: =C2=B7 You have a lot of names on the front page, the RFC=E2=80=99s= editor=E2=80=99s guidance is a max of 5 names on the front page. =C2=B7 Please ensure to run idnits (very verbose output), you may = want to check some of your references for updates. =C2=B7 Suggest to rename the heading of 4.2 to =E2=80=9CRRO SRLG su= b-object=E2=80=9D to clarify. =C2=B7 Section 5.1, the last sentence needs a =E2=80=9C.=E2=80=9D. =C2=B7 For the second paragraph, may want to consider using a separ= ate bullet item for the assignment of the new error subcode so as to make e= diting easier. Thanks, Deborah ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_90E64A62BD074FB3B0404EADE1159B52telefonicacom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
HI Deborah, Matt,

I can take care of the clean-up by the end of the week (I am in busine= ss trip now).

However, there is one thing I do not have a solution yet.. One of the = comments is about the number of authors.. There are 6 now... And the recomm= endation is 5...

Is 5 a recommendation or a MUST? Could we live with 6?

Oscar 

Enviado desde mi iPhone

El 21/1/2015, a las 16:25, BRUNGARD, DEBORAH A <db3546@att.com> escribi=C3=B3:

Hi Matt,

 <= /p>

You will need to clean up= the first page and check the references =E2=80=93 run nits and cleanup =E2= =80=93 before we can submit.

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisc= o.com]
Sent: Wednesday, January 21, 2015 4:18 PM
To: BRUNGARD, DEBORAH A; teas@ietf.= org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

We weren=E2=80=99t p= lanning on it=E2=80=A6 I=E2=80=99m just working on the assumption that we w= on=E2=80=99t get through the AD and IESG reviews without any comments at al= l, so there will be another revision at some stage and we could address your comments then.= Does that sound reasonable?

 

Cheers

 

Matt

 

Hi Matt,

 <= /p>

Are you planning to do an= other update? Lou and I were thinking that this was ready to submit for pub= lication?

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Matt Har= tley (mhartley) [mailto:mhartley@cisc= o.com]
Sent: Wednesday, January 21, 2015 3:13 PM
To: BRUNGARD, DEBORAH A; teas@ietf.= org
Cc: draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org; Matt Hartle= y (mhartley)
Subject: RE: progressing draft-ietf-teas-rsvp-te-srlg-collect

 

Deborah,<= /span>

 

Apologies for the la= te response =E2=80=93 this one got buried :)

 

Thanks for the comme= nts. Are you OK with us keeping them on the to-do list and addressing them = whenever we do a new revision of the doc?

 

Cheers

 

Matt

 

 

Authors (WG),

In preparing this document for publicat= ion, I found a few nits:

=C2=B7         You have a lot of names on = the front page, the RFC=E2=80=99s editor=E2=80=99s guidance is a max of 5 n= ames on the front page.

=C2=B7         Please ensure to run idnits= (very verbose output),  you may want to check some of your references= for updates.

=C2=B7         Suggest to rename the headi= ng of 4.2 to =E2=80=9CRRO SRLG sub-object=E2=80=9D to clarify.

=C2=B7         Section 5.1, the last sente= nce needs a =E2=80=9C.=E2=80=9D.

=C2=B7         For the second paragraph, m= ay want to consider using a separate bullet item for the assignment of the = new error subcode so as to make editing easier.

Thanks,

Deborah

 

 



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_90E64A62BD074FB3B0404EADE1159B52telefonicacom_-- From nobody Wed Jan 21 13:52:07 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1FD1A006D for ; Wed, 21 Jan 2015 13:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 jyNn27DI1ifX for ; Wed, 21 Jan 2015 13:52:03 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8655B1A005B for ; Wed, 21 Jan 2015 13:52:02 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 28f10c45.2b5510833940.423548.00-2431.1207569.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:52:02 +0000 (UTC) X-MXL-Hash: 54c01f824b4ead7d-716eb289195be4e39a2dbcec98e684827befe580 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id c7f10c45.0.423507.00-2297.1207449.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 21 Jan 2015 21:51:58 +0000 (UTC) X-MXL-Hash: 54c01f7e6e54706e-8e7c16d8e05cf951f152945b3201f93c4e6621ef Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LLpu9U021837; Wed, 21 Jan 2015 16:51:56 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0LLpjoK021685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jan 2015 16:51:49 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 21 Jan 2015 21:51:33 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.33]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 16:51:33 -0500 From: "BRUNGARD, DEBORAH A" To: OSCAR GONZALEZ DE DIOS Thread-Topic: progressing draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdAtJ/8Ojjl09jR6TI+4z2rqzFVqNQIjn4CgAAHrRcAAAFXVAAAAGkVwAADcb8oAAAPFcA== Date: Wed, 21 Jan 2015 21:51:32 +0000 Message-ID: References: <9D50FCE7413E3D4EA5E42331115FB5BC289F2E58@xmb-rcd-x03.cisco.com> <9D50FCE7413E3D4EA5E42331115FB5BC289F30F6@xmb-rcd-x03.cisco.com>, <90E64A62-BD07-4FB3-B040-4EADE1159B52@telefonica.com> In-Reply-To: <90E64A62-BD07-4FB3-B040-4EADE1159B52@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.179] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B4DC608MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=L/KqtZv8 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=Vme8EfoV89kA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=OTfaxyS_AAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=AUd_NHdVAAAA:8 a=RnxS3poO2ph9tn1UjDgA:9 a=QEXdDO2ut] X-AnalysisOut: [3YA:10 a=mzwbWt-2g836HKJH:21 a=0xiJHCbcwLOfEGuK:21 a=yMhMj] X-AnalysisOut: [lubAAAA:8 a=SSmOFEACAAAA:8 a=ThMAJqOgtWo4gP5VM6sA:9 a=gKO2] X-AnalysisOut: [Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg] X-AnalysisOut: [-hUA:10 a=SzD5b2PC-WNa97Ng:21 a=9rNTswu06A6ELwku:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "Matt Hartley \(mhartley\)" , "draft-ietf-teas-rsvp-te-srlg-collect@tools.ietf.org" , "teas@ietf.org" Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:52:05 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B4DC608MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT3NjYXIsDQoNClRoYW5rcyAtIEl0IG5lZWRzIHRvIGJlIGZpdmUg4oCTIFJGQyBlZGl0b3Ig Z3VpZGVsaW5lcy4NCg0KT25lIHBvc3NpYmxlIHNvbHV0aW9uIOKAkyBjaG9vc2UgYW4gZWRpdG9y IChvciB0d28pIGZvciB0aGUgZnJvbnQgYW5kIGxpc3QgdGhlIGF1dGhvcnMgYXQgdGhlIGVuZC4N Cg0KRnJvbTogT1NDQVIgR09OWkFMRVogREUgRElPUyBbbWFpbHRvOm9zY2FyLmdvbnphbGV6ZGVk aW9zQHRlbGVmb25pY2EuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1IDQ6 NDQgUE0NClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBDQpDYzogTWF0dCBIYXJ0bGV5IChtaGFydGxl eSk7IHRlYXNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdEB0 b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGVhcy1y c3ZwLXRlLXNybGctY29sbGVjdA0KDQpISSBEZWJvcmFoLCBNYXR0LA0KDQpJIGNhbiB0YWtlIGNh cmUgb2YgdGhlIGNsZWFuLXVwIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgKEkgYW0gaW4gYnVzaW5l c3MgdHJpcCBub3cpLg0KDQpIb3dldmVyLCB0aGVyZSBpcyBvbmUgdGhpbmcgSSBkbyBub3QgaGF2 ZSBhIHNvbHV0aW9uIHlldC4uIE9uZSBvZiB0aGUgY29tbWVudHMgaXMgYWJvdXQgdGhlIG51bWJl ciBvZiBhdXRob3JzLi4gVGhlcmUgYXJlIDYgbm93Li4uIEFuZCB0aGUgcmVjb21tZW5kYXRpb24g aXMgNS4uLg0KDQpJcyA1IGEgcmVjb21tZW5kYXRpb24gb3IgYSBNVVNUPyBDb3VsZCB3ZSBsaXZl IHdpdGggNj8NCg0KT3NjYXINCg0KRW52aWFkbyBkZXNkZSBtaSBpUGhvbmUNCg0KRWwgMjEvMS8y MDE1LCBhIGxhcyAxNjoyNSwgQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb208bWFp bHRvOmRiMzU0NkBhdHQuY29tPj4gZXNjcmliacOzOg0KSGkgTWF0dCwNCg0KWW91IHdpbGwgbmVl ZCB0byBjbGVhbiB1cCB0aGUgZmlyc3QgcGFnZSBhbmQgY2hlY2sgdGhlIHJlZmVyZW5jZXMg4oCT IHJ1biBuaXRzIGFuZCBjbGVhbnVwIOKAkyBiZWZvcmUgd2UgY2FuIHN1Ym1pdC4NClRoYW5rcywN CkRlYm9yYWgNCg0KDQpGcm9tOiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSBbbWFpbHRvOm1oYXJ0 bGV5QGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAxNSA0OjE4IFBN DQpUbzogQlJVTkdBUkQsIERFQk9SQUggQTsgdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRm Lm9yZz4NCkNjOiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3RAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGctY29sbGVjdEB0b29scy5p ZXRmLm9yZz47IE1hdHQgSGFydGxleSAobWhhcnRsZXkpDQpTdWJqZWN0OiBSRTogcHJvZ3Jlc3Np bmcgZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0DQoNCkRlYm9yYWgsDQoNCldl IHdlcmVu4oCZdCBwbGFubmluZyBvbiBpdOKApiBJ4oCZbSBqdXN0IHdvcmtpbmcgb24gdGhlIGFz c3VtcHRpb24gdGhhdCB3ZSB3b27igJl0IGdldCB0aHJvdWdoIHRoZSBBRCBhbmQgSUVTRyByZXZp ZXdzIHdpdGhvdXQgYW55IGNvbW1lbnRzIGF0IGFsbCwgc28gdGhlcmUgd2lsbCBiZSBhbm90aGVy IHJldmlzaW9uIGF0IHNvbWUgc3RhZ2UgYW5kIHdlIGNvdWxkIGFkZHJlc3MgeW91ciBjb21tZW50 cyB0aGVuLiBEb2VzIHRoYXQgc291bmQgcmVhc29uYWJsZT8NCg0KQ2hlZXJzDQoNCk1hdHQNCg0K SGkgTWF0dCwNCg0KQXJlIHlvdSBwbGFubmluZyB0byBkbyBhbm90aGVyIHVwZGF0ZT8gTG91IGFu ZCBJIHdlcmUgdGhpbmtpbmcgdGhhdCB0aGlzIHdhcyByZWFkeSB0byBzdWJtaXQgZm9yIHB1Ymxp Y2F0aW9uPw0KVGhhbmtzLA0KRGVib3JhaA0KDQoNCkZyb206IE1hdHQgSGFydGxleSAobWhhcnRs ZXkpIFttYWlsdG86bWhhcnRsZXlAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDIxLCAyMDE1IDM6MTMgUE0NClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBOyB0ZWFzQGlldGYub3Jn PG1haWx0bzp0ZWFzQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNybGct Y29sbGVjdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3Js Zy1jb2xsZWN0QHRvb2xzLmlldGYub3JnPjsgTWF0dCBIYXJ0bGV5IChtaGFydGxleSkNClN1Ympl Y3Q6IFJFOiBwcm9ncmVzc2luZyBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3QN Cg0KRGVib3JhaCwNCg0KQXBvbG9naWVzIGZvciB0aGUgbGF0ZSByZXNwb25zZSDigJMgdGhpcyBv bmUgZ290IGJ1cmllZCA6KQ0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gQXJlIHlvdSBPSyB3 aXRoIHVzIGtlZXBpbmcgdGhlbSBvbiB0aGUgdG8tZG8gbGlzdCBhbmQgYWRkcmVzc2luZyB0aGVt IHdoZW5ldmVyIHdlIGRvIGEgbmV3IHJldmlzaW9uIG9mIHRoZSBkb2M/DQoNCkNoZWVycw0KDQpN YXR0DQoNCg0KQXV0aG9ycyAoV0cpLA0KSW4gcHJlcGFyaW5nIHRoaXMgZG9jdW1lbnQgZm9yIHB1 YmxpY2F0aW9uLCBJIGZvdW5kIGEgZmV3IG5pdHM6DQrCtyAgWW91IGhhdmUgYSBsb3Qgb2YgbmFt ZXMgb24gdGhlIGZyb250IHBhZ2UsIHRoZSBSRkPigJlzIGVkaXRvcuKAmXMgZ3VpZGFuY2UgaXMg YSBtYXggb2YgNSBuYW1lcyBvbiB0aGUgZnJvbnQgcGFnZS4NCsK3ICBQbGVhc2UgZW5zdXJlIHRv IHJ1biBpZG5pdHMgKHZlcnkgdmVyYm9zZSBvdXRwdXQpLCAgeW91IG1heSB3YW50IHRvIGNoZWNr IHNvbWUgb2YgeW91ciByZWZlcmVuY2VzIGZvciB1cGRhdGVzLg0KwrcgIFN1Z2dlc3QgdG8gcmVu YW1lIHRoZSBoZWFkaW5nIG9mIDQuMiB0byDigJxSUk8gU1JMRyBzdWItb2JqZWN04oCdIHRvIGNs YXJpZnkuDQrCtyAgU2VjdGlvbiA1LjEsIHRoZSBsYXN0IHNlbnRlbmNlIG5lZWRzIGEg4oCcLuKA nS4NCsK3ICBGb3IgdGhlIHNlY29uZCBwYXJhZ3JhcGgsIG1heSB3YW50IHRvIGNvbnNpZGVyIHVz aW5nIGEgc2VwYXJhdGUgYnVsbGV0IGl0ZW0gZm9yIHRoZSBhc3NpZ25tZW50IG9mIHRoZSBuZXcg ZXJyb3Igc3ViY29kZSBzbyBhcyB0byBtYWtlIGVkaXRpbmcgZWFzaWVyLg0KVGhhbmtzLA0KRGVi b3JhaA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5z YWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRl bmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEg bm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24g eS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0 dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2Fq ZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVu dGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4g UGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpF c3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBz ZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBv dSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlk YWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlv IGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6Nv LCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBw cm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVz dGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Oj bw0K --_000_F64C10EAA68C8044B33656FA214632C83B4DC608MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIjsNCglwYW5vc2UtMToyIDUgNiA0IDUgNSA1 IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuZW1haWxxdW90ZSwgbGkuZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiLCJzZXJpZiI7DQoJY29sb3I6IzYz MjQyMzt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDI0ODY3MDQ5Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjAyNjYyMTEwMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBPc2Nhciw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAt IEl0IG5lZWRzIHRvIGJlIGZpdmUg4oCTIFJGQyBlZGl0b3IgZ3VpZGVsaW5lcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk9uZSBwb3NzaWJsZSBzb2x1dGlvbiDigJMgY2hvb3NlIGFuIGVkaXRvciAob3IgdHdvKSBmb3Ig dGhlIGZyb250IGFuZCBsaXN0IHRoZSBhdXRob3JzIGF0IHRoZSBlbmQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gT1NDQVIgR09OWkFMRVogREUgRElPUyBbbWFpbHRvOm9zY2FyLmdvbnphbGV6ZGVkaW9z QHRlbGVmb25pY2EuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAy MSwgMjAxNSA0OjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBCUlVOR0FSRCwgREVCT1JBSCBBPGJyPg0K PGI+Q2M6PC9iPiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsgdGVhc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0QHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBwcm9ncmVzc2luZyBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNv bGxlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhJIERlYm9yYWgsIE1hdHQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIHRha2UgY2FyZSBvZiB0aGUgY2xlYW4tdXAg YnkgdGhlIGVuZCBvZiB0aGUgd2VlayAoSSBhbSBpbiBidXNpbmVzcyB0cmlwIG5vdykuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIs IHRoZXJlIGlzIG9uZSB0aGluZyBJIGRvIG5vdCBoYXZlIGEgc29sdXRpb24geWV0Li4gT25lIG9m IHRoZSBjb21tZW50cyBpcyBhYm91dCB0aGUgbnVtYmVyIG9mIGF1dGhvcnMuLiBUaGVyZSBhcmUg NiBub3cuLi4gQW5kIHRoZSByZWNvbW1lbmRhdGlvbiBpcyA1Li4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIDUgYSByZWNvbW1lbmRhdGlv biBvciBhIE1VU1Q/IENvdWxkIHdlIGxpdmUgd2l0aCA2PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pc2NhciZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KRW52aWFkbyBkZXNk ZSBtaSBpUGhvbmUgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpFbCAyMS8xLzIwMTUsIGEgbGFzIDE2 OjI1LCBCUlVOR0FSRCwgREVCT1JBSCBBICZsdDs8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0dC5j b20iPmRiMzU0NkBhdHQuY29tPC9hPiZndDsgZXNjcmliacOzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWF0dCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSB3aWxsIG5lZWQgdG8g Y2xlYW4gdXAgdGhlIGZpcnN0IHBhZ2UgYW5kIGNoZWNrIHRoZSByZWZlcmVuY2VzIOKAkyBydW4g bml0cyBhbmQgY2xlYW51cCDigJMgYmVmb3JlIHdlIGNhbiBzdWJtaXQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVi b3JhaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSBbPGEgaHJlZj0ibWFpbHRvOm1oYXJ0bGV5QGNp c2NvLmNvbSI+bWFpbHRvOm1oYXJ0bGV5QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1IDQ6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IEJS VU5HQVJELCBERUJPUkFIIEE7IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGll dGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVh cy1yc3ZwLXRlLXNybGctY29sbGVjdEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi10ZWFzLXJz dnAtdGUtc3JsZy1jb2xsZWN0QHRvb2xzLmlldGYub3JnPC9hPjsgTWF0dCBIYXJ0bGV5IChtaGFy dGxleSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGVh cy1yc3ZwLXRlLXNybGctY29sbGVjdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0 MjMiPkRlYm9yYWgsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBP bGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+V2Ugd2VyZW7igJl0IHBsYW5uaW5nIG9u IGl04oCmIEnigJltIGp1c3Qgd29ya2luZyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHdlIHdvbuKA mXQgZ2V0IHRocm91Z2ggdGhlIEFEIGFuZCBJRVNHIHJldmlld3Mgd2l0aG91dCBhbnkgY29tbWVu dHMgYXQgYWxsLCBzbyB0aGVyZSB3aWxsDQogYmUgYW5vdGhlciByZXZpc2lvbiBhdCBzb21lIHN0 YWdlIGFuZCB3ZSBjb3VsZCBhZGRyZXNzIHlvdXIgY29tbWVudHMgdGhlbi4gRG9lcyB0aGF0IHNv dW5kIHJlYXNvbmFibGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21h biBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Q2hlZXJzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYz MjQyMyI+TWF0dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xk IFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWF0 dCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFyZSB5b3UgcGxhbm5pbmcgdG8gZG8gYW5vdGhlciB1cGRhdGU/IExvdSBh bmQgSSB3ZXJlIHRoaW5raW5nIHRoYXQgdGhpcyB3YXMgcmVhZHkgdG8gc3VibWl0IGZvciBwdWJs aWNhdGlvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5EZWJvcmFoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hdHQgSGFydGxleSAobWhhcnRsZXkpIFs8YSBo cmVmPSJtYWlsdG86bWhhcnRsZXlAY2lzY28uY29tIj5tYWlsdG86bWhhcnRsZXlAY2lzY28uY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUgMzox MyBQTTxicj4NCjxiPlRvOjwvYj4gQlJVTkdBUkQsIERFQk9SQUggQTsgPGEgaHJlZj0ibWFpbHRv OnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0QHRvb2xzLmlldGYu b3JnIj5kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zcmxnLWNvbGxlY3RAdG9vbHMuaWV0Zi5vcmc8 L2E+OyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogcHJv Z3Jlc3NpbmcgZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc3JsZy1jb2xsZWN0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+RGVib3JhaCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojNjMyNDIzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5B cG9sb2dpZXMgZm9yIHRoZSBsYXRlIHJlc3BvbnNlIOKAkyB0aGlzIG9uZSBnb3QgYnVyaWVkIDop PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzYzMjQyMyI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIEFyZSB5b3UgT0sg d2l0aCB1cyBrZWVwaW5nIHRoZW0gb24gdGhlIHRvLWRvIGxpc3QgYW5kIGFkZHJlc3NpbmcgdGhl bSB3aGVuZXZlciB3ZSBkbyBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZG9jPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiM2MzI0MjMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2 MzI0MjMiPkNoZWVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4g T2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPk1hdHQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojNjMyNDIzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5BdXRob3JzIChXRyksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBwcmVwYXJp bmcgdGhpcyBkb2N1bWVudCBmb3IgcHVibGljYXRpb24sIEkgZm91bmQgYSBmZXcgbml0czo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDowaW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WW91IGhh dmUgYSBsb3Qgb2YgbmFtZXMgb24gdGhlIGZyb250IHBhZ2UsIHRoZSBSRkPigJlzIGVkaXRvcuKA mXMgZ3VpZGFuY2UgaXMgYSBtYXggb2YgNSBuYW1lcyBvbiB0aGUgZnJvbnQgcGFnZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBsZWFzZSBlbnN1cmUgdG8g cnVuIGlkbml0cyAodmVyeSB2ZXJib3NlIG91dHB1dCksJm5ic3A7IHlvdSBtYXkgd2FudCB0byBj aGVjayBzb21lIG9mIHlvdXIgcmVmZXJlbmNlcyBmb3IgdXBkYXRlcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1Z2dlc3QgdG8gcmVuYW1lIHRoZSBoZWFk aW5nIG9mIDQuMiB0byDigJxSUk8gU1JMRyBzdWItb2JqZWN04oCdIHRvIGNsYXJpZnkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9uIDUuMSwgdGhl IGxhc3Qgc2VudGVuY2UgbmVlZHMgYSDigJwu4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCBtYXkgd2FudCB0 byBjb25zaWRlciB1c2luZyBhIHNlcGFyYXRlIGJ1bGxldCBpdGVtIGZvciB0aGUgYXNzaWdubWVu dCBvZiB0aGUgbmV3IGVycm9yIHN1YmNvZGUgc28gYXMgdG8gbWFrZSBlZGl0aW5nIGVhc2llci48 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5EZWJvcmFoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0K PGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPjxicj4N CkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRh IG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBl bnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNh ZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5z bWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0K IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFu ZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mg c2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250 ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVz byBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kg dm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8g ZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3Bp YSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVn aXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9n YW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21h IHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F64C10EAA68C8044B33656FA214632C83B4DC608MISOUT7MSGUSRDE_-- From nobody Wed Jan 21 22:27:15 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761C61AC41E for ; Wed, 21 Jan 2015 22:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fQJ1UoScB-iW for ; Wed, 21 Jan 2015 22:27:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752B81AC41A for ; Wed, 21 Jan 2015 22:27:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH48714; Thu, 22 Jan 2015 06:27:07 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 22 Jan 2015 06:27:06 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 22 Jan 2015 14:26:58 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , "adrian@olddog.co.uk" , "'Cyril Margaria'" , "teas@ietf.org" Thread-Topic: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro Thread-Index: AQHQNVr9dH35x7e0C0KWlfGiWrWoGZzJ8hOAgAB6yYCAAT6sUA== Date: Thu, 22 Jan 2015 06:26:58 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927338335ED@nkgeml512-mbx.china.huawei.com> References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> <011b01d03571$7526d480$5f747d80$@olddog.co.uk> <54BFFB31.6050102@labn.net> In-Reply-To: <54BFFB31.6050102@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org" , "draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org" , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 06:27:13 -0000 Hi Lou,=20 Thanks a lot for providing the suggested description. I think it specifies = a reasonable rule of using the ERO Hop Attributes subobject in the loopback= scenario.=20 Adrian, if you also like it, I can update the draft accordingly. Many thanks, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Thursday, January 22, 2015 3:17 AM > To: adrian@olddog.co.uk; 'Cyril Margaria'; teas@ietf.org > Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org; > draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org; > draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro >=20 > [ccamp dropped response doesn't concern the WSON draft] On 1/21/2015 6:57 > AM, Adrian Farrel wrote: > >> For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV > >> to > >> > explicit nodes, precluding link ids): > >> > The Attribute Flags TLV with Loopback Attribute Flag set MUST be > >> > present after an explicit Hop addressing an TE Router ID > >> > identifying a specific node or a Link ID identifying an incoming TE > >> > link. it MUST NOT be present after a loose, abstract node, Link > >> > ID identifying an outgoing TE link, Component Interface ID or Label. > > Ah, joy! > > Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb. > > I've made a note in the data tracker and marked that I-D as needing a > > new revision. > > > I think this phrasing is too restrictive as it may be possible to put som= e of the > identified items into loopback in some technologies, e.g., an output inte= rface. > How about: >=20 > after: > The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to = address > the loopback request > to the particular node. > add: > The ingress MUST ensure that the desired loopback mode is strictly > identified in the ERO. > and > OLD: >=20 > If the bit is set, the node SHOULD try to put the LSP into loopback mo= de. > NEW > If the bit is set, the node MUST check that the desired loopback is s= trictly > identified by verifying that the L bit is set to 0 in both the ERO Ho= p > Attributes subobject and the prior subobject. The prior subobject > MUST also be checked to ensure that it provides strict identification= . > Currently, the type value MUST be verified to be less than 32, and > for type values 1 and 2 the prefix length MUST be 32 and 128 respecti= vely. > If the desired loopback is not strictly identified the request MUST b= e > ignored > and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. >=20 > Otherwise, the node SHOULD try to put the LSP into loopback mode. >=20 >=20 > Lou >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jan 22 04:34:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1641ACCDA for ; Thu, 22 Jan 2015 04:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 BXZHBa7DahDr for ; Thu, 22 Jan 2015 04:34:15 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7261ACC85 for ; Thu, 22 Jan 2015 04:34:15 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MCY7tR001074; Thu, 22 Jan 2015 12:34:07 GMT Received: from 950129200 (089144198119.atnat0007.highway.a1.net [89.144.198.119]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MCY460001046 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:34:05 GMT From: "Adrian Farrel" To: "'Dongjie \(Jimmy\)'" , "'Lou Berger'" , "'Cyril Margaria'" , References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> <011b01d03571$7526d480$5f747d80$@olddog.co.uk> <54BFFB31.6050102@labn.net> <76CD132C3ADEF848BD84D028D243C927338335ED@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927338335ED@nkgeml512-mbx.china.huawei.com> Date: Thu, 22 Jan 2015 12:34:02 -0000 Message-ID: <049301d0363f$b6960930$23c21b90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNJKbqcA8ICrxY/nQ0vdspVCXFtAG4lZZaAh+pWEECE1iS0AJBBEVYm5DQwhA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.006 X-TM-AS-Result: No--26.908-10.0-31-10 X-imss-scan-details: No--26.908-10.0-31-10 X-TMASE-MatchedRID: WMT2WRIkHPNjDV//SvkH3uG5dRZCgxC3t3aeg7g/usAutoY2UtFqGHt9 lZQ/1yXW6DsG/OV4bTAfKB6Ydcn12hLn4nGgmm6XHjsQaSkZ4D3g1aQ5xIq7lA0ymGrfpmJg0/x bS3+sxpS7Lkv3NhTUTTOhQ0C0WOxyQsxxYYsqaFZH4a2iJdV4MaKaxHqGRwkCftUOKYKOYt8cPh W63s0GgrYSvTbcTKGCGsIztItoYip++hOMsDz7cpLPLrFS265Pwx0jRRxcQfOyg9mQXdx4tR/XW BLkU7fulG2UxuvfLSq1xYWoj8mhQRMI+YRurTF4qeBupNgLgYcUkWvaqUqLH7IPyqeQTeKkC50X 6/IN7MA/GFQFyEqlKV4ujvAXyDCCQeCII4Mx0e/qsFlQXzLr6Pp70sHw22glNwCgQD6pGqYONnC OtDoJBZ6Ss6O2bihGHDnwvr6B+jQYB2fOueQzjzl/1fD/Gopd2K+lN2ZUJHbEQdG7H66TyOk/y0 w7JiZo Archived-At: Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 12:34:17 -0000 Yes, please! Update and post. Adrian > -----Original Message----- > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > Sent: 22 January 2015 06:27 > To: Lou Berger; adrian@olddog.co.uk; 'Cyril Margaria'; teas@ietf.org > Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org; draft-ietf-teas-lsp-attribute- > ro.all@tools.ietf.org; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: RE: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro > > Hi Lou, > > Thanks a lot for providing the suggested description. I think it specifies a > reasonable rule of using the ERO Hop Attributes subobject in the loopback > scenario. > > Adrian, if you also like it, I can update the draft accordingly. > > Many thanks, > Jie > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: Thursday, January 22, 2015 3:17 AM > > To: adrian@olddog.co.uk; 'Cyril Margaria'; teas@ietf.org > > Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org; > > draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org; > > draft-ietf-ccamp-wson-signaling@tools.ietf.org > > Subject: Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro > > > > [ccamp dropped response doesn't concern the WSON draft] On 1/21/2015 6:57 > > AM, Adrian Farrel wrote: > > >> For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV > > >> to > > >> > explicit nodes, precluding link ids): > > >> > The Attribute Flags TLV with Loopback Attribute Flag set MUST be > > >> > present after an explicit Hop addressing an TE Router ID > > >> > identifying a specific node or a Link ID identifying an incoming TE > > >> > link. it MUST NOT be present after a loose, abstract node, Link > > >> > ID identifying an outgoing TE link, Component Interface ID or Label. > > > Ah, joy! > > > Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb. > > > I've made a note in the data tracker and marked that I-D as needing a > > > new revision. > > > > > I think this phrasing is too restrictive as it may be possible to put some of the > > identified items into loopback in some technologies, e.g., an output interface. > > How about: > > > > after: > > The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to address > > the loopback request > > to the particular node. > > add: > > The ingress MUST ensure that the desired loopback mode is strictly > > identified in the ERO. > > and > > OLD: > > > > If the bit is set, the node SHOULD try to put the LSP into loopback mode. > > NEW > > If the bit is set, the node MUST check that the desired loopback is strictly > > identified by verifying that the L bit is set to 0 in both the ERO Hop > > Attributes subobject and the prior subobject. The prior subobject > > MUST also be checked to ensure that it provides strict identification. > > Currently, the type value MUST be verified to be less than 32, and > > for type values 1 and 2 the prefix length MUST be 32 and 128 respectively. > > If the desired loopback is not strictly identified the request MUST be > > ignored > > and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. > > > > Otherwise, the node SHOULD try to put the LSP into loopback mode. > > > > > > Lou > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Jan 22 06:37:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558BC1AC82C; Thu, 22 Jan 2015 06:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 77O84AxtI1xf; Thu, 22 Jan 2015 06:37:43 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA9F1A1ABF; Thu, 22 Jan 2015 06:37:39 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MEbZJ5009837; Thu, 22 Jan 2015 14:37:35 GMT Received: from 950129200 (089144198119.atnat0007.highway.a1.net [89.144.198.119]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0MEbXjC009827 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 14:37:34 GMT From: "Adrian Farrel" To: Date: Thu, 22 Jan 2015 14:37:33 -0000 Message-ID: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.007 X-TM-AS-Result: No--19.843-10.0-31-10 X-imss-scan-details: No--19.843-10.0-31-10 X-TMASE-MatchedRID: /A3iJdYWyCunykMun0J1wnBRIrj8R47FNACnndLvXwdX14Hy+eYp73AX R/gLaDwarOalo+a/5deFmDcBAhudcAVnfa7xoeys/1aBDnIV4imimsR6hkcJAr2x/79DT1I/gK6 qCGa1Z9cG65bsEKQueqaJO1uj7lcxbXK/7rgzL95mg36YZWG/2zUDvpRQufxV1gisw2JKo8n+56 dY8RnEnHn/mRv5OVPuihwSHjzho2IMeUy96gk4BE0jzafXv7tT4+ZcrqvCDkGdCqKtxM6bh3ptC 95MCcU3G7GrT+gcmmHCnAfeoR8P7jEd5Rr1QIbu4mYxmYubDHlumyzHXqTNN/gnJH5vm2+gmAIy Wr6xn59K29r+eqX9Us8TE54NfbwyKUe58oALvqztMsi+dai/0ZZ6zKu0q4rtPcFkClcmQNvUUZk D7yFSUp6XL0ZhMPWRHMTZ1n5h9cnZQ3o4nYfte7mR+C0l9vjVD915jeHUf0NnnK6mXN72mz7P7M GYmBY1z8BkUFuVJnIrnoKhIVAscAX3hSIN+ZbKvHKClHGjjr3Lvf5EDoNoipyka59saICoFOkP8 eIKDD/X/WWdc9WcUBWsRvtG4mXEY+VfsshMgK2QOktEo73GFDFcf92WG8u/grAXgr/AjP0d3EuW Nq2ydsPS8gXowCmwlVGcUvASQ6DtunZmiKG7o6xET38Y1QZhtDSfcMR+7ZPbDWJ63HXnfzkw0AF 9zMGE9PpTwwvqom+Rk6XtYogiarQ/aqQZTRfKC24oEZ6SpSk+Mqg+CyrtwA== Archived-At: Cc: Alvaro Retana , teas@ietf.org Subject: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 14:37:46 -0000 Authors, Thanks for this document which I found clear and not too long. I have done my usual AD review to try to flush out any issues that might otherwise show up in IETF last call or IESG review. The only largish issue I have is about error conditions. Pretty much the only error handling I see is in 5.3 where you have: An egress node, upon receiving a Path message containing an ASSOCIATION or Extended ASSOCIATION Object with Association Type set to "Single Sided Associated Bidirectional LSP" MUST create an LSP in the reverse direction or reject the Path message by sending a PathErr. ...but you don't say what reason code to give. You need to handle some other error conditions such as... **** race conditions **** what if the association is triggered by both ends at the same time? **** what if the reverse dirn LSP has already been associated with something else? **** failure conditions **** what if not willing or able to associate? **** what if set-up of reverse LSP fails? **** what if requested REVERSE LSP parameters are not acceptable? **** what if the remote end point doesn't support the association mechanism defined here? how will the initiator know? I also have some smaller points as set out below. I'll put the I-D into "revised I-D needed" state while we discuss these points and while you produce an update. Thanks for the work, Adrian ==== You have a different number of font-page authors and names in the Authors' Addresses section. Looks like Fan Yang and Weilian Jiang should be moved to a Contributors section. --- Section 1 is OK, but it would have been better to just list the relevant requirements (7, 11, 12, 50) and then the additional requirement (14). Probably no need to change now, but my preference is to avoid the risk of introducing an error during the copying or editorial process. If you feel like making this change, I would be happier. --- Because you use RBNF in section 4, you need to add a statement to Section 2 like: This document uses the Routing Backus-Naur Form (RBNF) to define message formats as defined in [RFC5511]. And then, of course, add a normative reference. --- I think 2.1.1 is missing an important statement about co-routing. "A pair of reverse unidirectional LSPs that are associated to form an associated bidirectional LSP do not necessarily follow the same path through the network. If they do follow the same path, they are known as 'co-routed'." --- 3.1 This section provides an overview and definition of the models for provisioning bidirectional LSPs. This is missing the word "associated" to read "associated bidirectional" --- Shouldn't 3.1.1 also mention the REVERSE_LSP Object. Something like... For the single sided provisioning, the Traffic Engineering (TE) tunnel is configured only on one endpoint. An LSP for this tunnel is initiated by the initiating endpoint with the (Extended) ASSOCIATION Object inserted in the Path message. The other endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using information from the REVERSE_LSP Object if present. --- 3.1.2 Pedantry, but... OLD For the double sided provisioning, two unidirectional TE tunnels are configured independently on both endpoints. NEW For the double sided provisioning, two unidirectional TE tunnels are configured independently, one on each endpoint. END --- 3.2 This section provides an overview of the association signaling methods for the bidirectional LSPs. Again, this is missing "associated" --- 3.2.1 OLD LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted in the Path message, in which the Association Type indicating single sided provisioning. NEW LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted in the Path message, in which the Association Type indicating single sided provisioning is included. END --- 3.2.2 OLD For the double sided provisioning model, both LSP1 and LSP2 are signaled independently with (Extended) ASSOCIATION Object inserted in the Path message, in which the Association Type indicating double sided provisioning. NEW For the double sided provisioning model, both LSP1 and LSP2 are signaled independently with (Extended) ASSOCIATION Object inserted in the Path message, in which the Association Type indicating double sided provisioning is included. --- 3.2.2 needs to include some comment about how the two LSPs are selected to be associated. I think this is simply "by management action applied at both end points", although I wonder whether it is enough to apply the action at just one end point because the association object will achieve the desired result. Please think about this and add a note. --- Section 3.3.1 is fine as it is, but I think that it makes it look like the REVERSE LSP object is only used for asymmetric b/w. Perhaps... OLD As described in this document, addition of the REVERSE_LSP Object also allows the initiating node to control the reverse LSP by including other existing objects in a REVERSE_LSP Object. NEW As described in Section 4.4, addition of the REVERSE_LSP Object also allows the initiating node to control other aspects of the reverse LSP (such as its path) by including other subobjects in a REVERSE_LSP Object. END --- For clarity 3.4 needs to observe that multiple association objects may be present in the signaling of a single LSP. --- 4.2 The new Association Types are defined as follows (values are temporary early allocations as per RFC7120): Delete the bit in brackets, please, so that we don't accidentally find it in the published RFC. Your message is already in 6.1 (which is good). --- 4.4.1 Class_Num = 203 (of the form 11bbbbbb), C_Type = 1 (values are temporary early allocations as per RFC7120) Same thing. Please remove the bit about early allocation. (BTW, you have "of the form 11bbbbbb" twice in this section. --- 4.4.2 or 5.2 Maybe... The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object. --- 5.2 An egress node MUST tear down and reestablish a new reverse LSP when REVERSE_LSP Object is either added or removed in the received Path message. That's confusing! - Why is modification of an existing LSP not allowed? - Why does removal of the REVERSE_LSP object require tearing down and reestablishment since all that has happened is that the requirements for the reverse LSP have been relaxed? - Why does addition of the REVERSE_LSP necessarily require tear down and reestablishment when the existing LSP might already satisfy the requirements? - Is make-before-break used or is this assumed to be an out-of-service operation? If out-of-service you need to describe how that is achieved (e.g., using LI). --- 5.3 has If REVERSE_LSP Object is not present in the received Path message of the LSP, the egress node SHOULD use the LSP properties from the received LSP Path message to signal the LSP in the reverse direction (which may depend on the local policy). This worries me. Do you mean that in the absence of a REVERSE_LSP object containing an ERO, the reverse LSP MUST be co-routed with the forward LSP? From nobody Thu Jan 22 07:43:27 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10071A1AD0; Thu, 22 Jan 2015 07:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] autolearn=no 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 jJnx-AJPf53C; Thu, 22 Jan 2015 07:43:18 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F0A1A1AC9; Thu, 22 Jan 2015 07:43:18 -0800 (PST) Received: from localhost ([::1]:37502) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YEJue-0004Pu-My; Thu, 22 Jan 2015 18:43:16 +0300 Message-ID: <54C11A90.4000205@labn.net> Date: Thu, 22 Jan 2015 10:43:12 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org References: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> In-Reply-To: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: Alvaro Retana , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 15:43:20 -0000 Adrian, one comment based on a quick read of your (as usual, very good) comments. On 1/22/2015 9:37 AM, Adrian Farrel wrote: > ... > --- > > I think 2.1.1 is missing an important statement about co-routing. > > "A pair of reverse unidirectional LSPs that are associated to form an > associated bidirectional LSP do not necessarily follow the same path > through the network. If they do follow the same path, they are known as > 'co-routed'." actually, I disagree. Co-routed is defined ([RFC5654]) to mean that both directions are fully managed, including protection, as a single entity so I don't think this qualifies. Lou From nobody Thu Jan 22 08:31:01 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3211A1A17; Thu, 22 Jan 2015 08:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 97MiKPvn3fPG; Thu, 22 Jan 2015 08:30:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7571A1AD3; Thu, 22 Jan 2015 08:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8086; q=dns/txt; s=iport; t=1421944236; x=1423153836; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zCGI0YzeDXNl2UGt94Z6c6xuGxTg0YWydXW0VKQvzBc=; b=UduXCa8eXowI/tvbOFbZdm1xKNE38yoWFsmEbVUnd4f0p6t+mcakOtLd Pw0vvsTNtilPpgoqYrtQ0f2HlaCed5Yp5RokmWWSZmssRi0AtvObYEVqH sUuPROJc/485ic45PFuZ9FYUkjazvqq7UKhg0ZEuvvV0TOC2gEN18bU/Y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAGokwVStJV2S/2dsb2JhbABagwaBKgTMMgKBFUMBAQEBAX2EDQIEOj8SAQg2QiUBAQQOBYgs0zABAQEBAQEBAQEBAQEBAQEBAQEBGY95B4QpBY5miRmBFIJ+gkGFM4Jygz0ig25vgQMkHn4BAQE X-IronPort-AV: E=Sophos;i="5.09,449,1418083200"; d="scan'208";a="389970695" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jan 2015 16:30:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0MGUYa0027433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 16:30:34 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 10:30:34 -0600 From: "Rakesh Gandhi (rgandhi)" To: "adrian@olddog.co.uk" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" Thread-Topic: AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiAAGCxIA Date: Thu, 22 Jan 2015 16:30:34 +0000 Message-ID: In-Reply-To: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> 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: [161.44.212.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <69731B8EDCB1A84AA390E8DC75054753@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:30:46 -0000 Hi Adrian, Thank you for the thorough review of the document and detailed comments. We will digest and advise accordingly. Many Thanks, Rakesh On 2015-01-22 9:37 AM, "Adrian Farrel" wrote: >Authors, > =20 >Thanks for this document which I found clear and not too long. > >I have done my usual AD review to try to flush out any issues that >might otherwise show up in IETF last call or IESG review. > >The only largish issue I have is about error conditions. Pretty much the >only error handling I see is in 5.3 where you have: > > An egress node, upon receiving a Path message containing an > ASSOCIATION or Extended ASSOCIATION Object with Association Type set > to "Single Sided Associated Bidirectional LSP" MUST create an LSP in > the reverse direction or reject the Path message by sending a > PathErr. > >...but you don't say what reason code to give. > >You need to handle some other error conditions such as... > >**** race conditions >**** what if the association is triggered by both ends at the same time? >**** what if the reverse dirn LSP has already been associated with > something else? > >**** failure conditions >**** what if not willing or able to associate? >**** what if set-up of reverse LSP fails? >**** what if requested REVERSE LSP parameters are not acceptable? >**** what if the remote end point doesn't support the association > > mechanism defined here? how will the initiator know? > > >I also have some smaller points as set out below. > >I'll put the I-D into "revised I-D needed" state while we discuss these >points and while you produce an update. > >Thanks for the work, >Adrian > >=3D=3D=3D=3D > >You have a different number of font-page authors and names in the >Authors' Addresses section. > >Looks like Fan Yang and Weilian Jiang should be moved to a >Contributors section. > >--- > >Section 1 is OK, but it would have been better to just list the relevant >requirements (7, 11, 12, 50) and then the additional requirement (14). > >Probably no need to change now, but my preference is to avoid the risk >of introducing an error during the copying or editorial process. If you >feel like making this change, I would be happier. > >--- > >Because you use RBNF in section 4, you need to add a statement to >Section 2 like: > > This document uses the Routing Backus-Naur Form (RBNF) to define > message formats as defined in [RFC5511]. > >And then, of course, add a normative reference. > >--- > >I think 2.1.1 is missing an important statement about co-routing. > >"A pair of reverse unidirectional LSPs that are associated to form an >associated bidirectional LSP do not necessarily follow the same path >through the network. If they do follow the same path, they are known as >'co-routed'." > >--- > >3.1 > > This section provides an overview and definition of the models for > provisioning bidirectional LSPs. > >This is missing the word "associated" to read "associated bidirectional" > >--- > >Shouldn't 3.1.1 also mention the REVERSE_LSP Object. Something like... > > For the single sided provisioning, the Traffic Engineering (TE) > tunnel is configured only on one endpoint. An LSP for this tunnel is > initiated by the initiating endpoint with the (Extended) ASSOCIATION > Object inserted in the Path message. The other endpoint then creates > the corresponding reverse TE tunnel and signals the reverse LSP in > response using information from the REVERSE_LSP Object if present. > >--- > >3.1.2 > >Pedantry, but... > >OLD > For the double sided provisioning, two unidirectional TE tunnels are > configured independently on both endpoints. >NEW > For the double sided provisioning, two unidirectional TE tunnels are > configured independently, one on each endpoint. >END > >--- > >3.2 > > This section provides an overview of the association signaling > methods for the bidirectional LSPs. > >Again, this is missing "associated" > >--- > >3.2.1 > >OLD > LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted > in the Path message, in which the Association Type indicating single > sided provisioning. >NEW > LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted > in the Path message, in which the Association Type indicating single > sided provisioning is included. >END > >--- > >3.2.2 > >OLD > For the double sided provisioning model, both LSP1 and LSP2 are > signaled independently with (Extended) ASSOCIATION Object inserted in > the Path message, in which the Association Type indicating double > sided provisioning. >NEW > For the double sided provisioning model, both LSP1 and LSP2 are > signaled independently with (Extended) ASSOCIATION Object inserted in > the Path message, in which the Association Type indicating double > sided provisioning is included. > >--- > >3.2.2 needs to include some comment about how the two LSPs are selected >to be associated. I think this is simply "by management action applied >at both end points", although I wonder whether it is enough to apply the >action at just one end point because the association object will achieve >the desired result. > >Please think about this and add a note. > >--- > >Section 3.3.1 is fine as it is, but I think that it makes it look like >the REVERSE LSP object is only used for asymmetric b/w. Perhaps... > >OLD > As > described in this document, addition of the REVERSE_LSP Object also > allows the initiating node to control the reverse LSP by including > other existing objects in a REVERSE_LSP Object. >NEW > As > described in Section 4.4, addition of the REVERSE_LSP Object also > allows the initiating node to control other aspects of the reverse > LSP (such as its path) by including other subobjects in a REVERSE_LSP > Object. >END > >--- > >For clarity 3.4 needs to observe that multiple association objects may >be present in the signaling of a single LSP. > >--- > >4.2 > > The new Association Types are defined as follows (values are > temporary early allocations as per RFC7120): > >Delete the bit in brackets, please, so that we don't accidentally find >it in the published RFC. Your message is already in 6.1 (which is good). > =20 >--- > >4.4.1 > > Class_Num =3D 203 (of the form 11bbbbbb), C_Type =3D 1 (values are > temporary early allocations as per RFC7120) > >Same thing. Please remove the bit about early allocation. > >(BTW, you have "of the form 11bbbbbb" twice in this section. > >--- > >4.4.2 or 5.2 > >Maybe... > > The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object. > >--- > >5.2 > > An > egress node MUST tear down and reestablish a new reverse LSP when > REVERSE_LSP Object is either added or removed in the received Path > message. > >That's confusing! >- Why is modification of an existing LSP not allowed? >- Why does removal of the REVERSE_LSP object require tearing down and > reestablishment since all that has happened is that the requirements > for the reverse LSP have been relaxed? >- Why does addition of the REVERSE_LSP necessarily require tear down > and reestablishment when the existing LSP might already satisfy the > requirements? >- Is make-before-break used or is this assumed to be an out-of-service > operation? If out-of-service you need to describe how that is > achieved (e.g., using LI). > >--- > >5.3 has > > If REVERSE_LSP Object is not present in the received Path message of > the LSP, the egress node SHOULD use the LSP properties from the > received LSP Path message to signal the LSP in the reverse direction > (which may depend on the local policy). > >This worries me. Do you mean that in the absence of a REVERSE_LSP object >containing an ERO, the reverse LSP MUST be co-routed with the forward >LSP? > From nobody Thu Jan 22 18:26:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FADE1B2BB7; Thu, 22 Jan 2015 18:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VCon2XjNyl2Q; Thu, 22 Jan 2015 18:26:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6E1B2B9A; Thu, 22 Jan 2015 18:26:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123022614.9293.22432.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 18:26:14 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 02:26:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Authors : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-teas-rsvp-te-li-lb-03.txt Pages : 8 Date : 2015-01-22 Abstract: This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) as control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 22 18:44:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AFF1B2BB0 for ; Thu, 22 Jan 2015 18:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Lli1prraSTeW for ; Thu, 22 Jan 2015 18:44:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A7B1B2B9D for ; Thu, 22 Jan 2015 18:44:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ46711; Fri, 23 Jan 2015 02:44:19 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 02:44:19 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 10:44:14 +0800 From: "Dongjie (Jimmy)" To: "adrian@olddog.co.uk" , Lou Berger Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt Thread-Index: AQHQNrQMUL6v1GDLXUG+hnF241AVsJzM/VSA Date: Fri, 23 Jan 2015 02:44:14 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92733835B8C@nkgeml512-mbx.china.huawei.com> References: <20150123022614.9293.22432.idtracker@ietfa.amsl.com> In-Reply-To: <20150123022614.9293.22432.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 02:44:24 -0000 Dear Adrian, Lou and all,=20 This revision adds the rules of using ERO Hop Attributes subobject in the l= oopback scenario. Your review and comments are always appreciated. Many thanks, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 23, 2015 10:26 AM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Traffic Engineering Architecture and Si= gnaling > Working Group of the IETF. >=20 > Title : GMPLS RSVP-TE Extensions for Lock Instruct and > Loopback > Authors : Jie Dong > Mach(Guoyi) Chen > Zhenqiang Li > Daniele Ceccarelli > Filename : draft-ietf-teas-rsvp-te-li-lb-03.txt > Pages : 8 > Date : 2015-01-22 >=20 > Abstract: > This document specifies extensions to Resource Reservation Protocol- > Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and > Loopback (LB) mechanisms for Label Switched Paths (LSPs). These > mechanisms are applicable to technologies which use Generalized > Multi-Protocol Label Switching (GMPLS) as control plane. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-li-lb-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Jan 23 05:42:37 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68E21A90C4; Fri, 23 Jan 2015 05:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 MAu0HDwp6sZX; Fri, 23 Jan 2015 05:42:33 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150881A90C0; Fri, 23 Jan 2015 05:42:32 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NDgSIq007872; Fri, 23 Jan 2015 13:42:28 GMT Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NDgQdL007864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 13:42:27 GMT From: "Adrian Farrel" To: "'Lou Berger'" , References: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> <54C11A90.4000205@labn.net> In-Reply-To: <54C11A90.4000205@labn.net> Date: Fri, 23 Jan 2015 13:42:24 -0000 Message-ID: <003801d03712$6cfd8f40$46f8adc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKnjyiTRD2fR4Htm7ZfeuriAI2w5AMerqBWmwYQWtA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21276.004 X-TM-AS-Result: No--13.445-10.0-31-10 X-imss-scan-details: No--13.445-10.0-31-10 X-TMASE-MatchedRID: oTBA/+sdKaanykMun0J1wqam63kopwnTIHYIZed9zXVrH7R0RhorDE1Q fiOoMJEUTWLw2jvbfpxS13xU66XgGsDxbnxe/DuI/1aBDnIV4ikZskwWqoib3HGGWh2ABW0vwB8 gzNQ+eE4Rfp4vG86mZjeT288mssTUxEEtnnH5KRcI8o+oRtTdk5OBXaF4TRYNMKZRiezcUtPQWI OoOVCAfm1A074OquSOWJcq1bYi/JR24yrUc9TPnDL8qUdZlzy0fS0Ip2eEHny+qryzYw2E8H2PY bDNMTe9KrauXd3MZDWYVrh0J+4BnSafEnxmZx3h/ySw343ACvMmJkhhGN6XoP9bOxSRJ5aq Archived-At: Cc: 'Alvaro Retana' , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:42:36 -0000 OK, yes, good catch, thanks. Once a year I come back to read that definition and recall that I never liked it :-) But it is what it is. A > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 22 January 2015 15:43 > To: adrian@olddog.co.uk; draft-ietf-teas-mpls-tp-rsvpte-ext-associated- > lsp.all@ietf.org > Cc: Alvaro Retana; teas@ietf.org > Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated- > lsp > > Adrian, > one comment based on a quick read of your (as usual, very good) > comments. > > On 1/22/2015 9:37 AM, Adrian Farrel wrote: > > ... > > > --- > > > > I think 2.1.1 is missing an important statement about co-routing. > > > > "A pair of reverse unidirectional LSPs that are associated to form an > > associated bidirectional LSP do not necessarily follow the same path > > through the network. If they do follow the same path, they are known as > > 'co-routed'." > actually, I disagree. Co-routed is defined ([RFC5654]) to mean that > both directions are fully managed, including protection, as a single > entity so I don't think this qualifies. > > Lou From nobody Fri Jan 23 05:42:39 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8871A90CD for ; Fri, 23 Jan 2015 05:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 a7J0HDHXNMgM for ; Fri, 23 Jan 2015 05:42:36 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7551A90C5 for ; Fri, 23 Jan 2015 05:42:35 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NDgUxa007886; Fri, 23 Jan 2015 13:42:30 GMT Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NDgQdM007864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 13:42:28 GMT From: "Adrian Farrel" To: "'Dongjie \(Jimmy\)'" , "'Lou Berger'" References: <20150123022614.9293.22432.idtracker@ietfa.amsl.com> <76CD132C3ADEF848BD84D028D243C92733835B8C@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C92733835B8C@nkgeml512-mbx.china.huawei.com> Date: Fri, 23 Jan 2015 13:42:24 -0000 Message-ID: <003901d03712$6e3ffa50$4abfeef0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqQvD/aieVsGwEHndUe8f493Pc6AIO/uxKm4klekA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21276.004 X-TM-AS-Result: No--15.182-10.0-31-10 X-imss-scan-details: No--15.182-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F6qMZyz/RcGLuYAh37ZsBDCQrO4XR6BRQO638ZUY6gSd1/Y v1Xbg3AhTWLw2jvbfpwQIIqVNQDiwR6Hacd6Ohq7Qz/LkQyz8mZF0vHVf0FWQLKD2ZBd3Hi1735 pELcvjuprhG3PWXSTBLH8UeNOUG6lP17Pn4hNg5+4jAucHcCqnVF5adRR2Ej12dP9ypSe+fd6bQ veTAnFN1i3UDfbOv+HwU88oMHuAJxtQL4HPI4j31aOpp/sV5nVQBnqdxuJ5SCM2ehTV+imi55su tRzc0n8AdWX+YOlswkQJOrWF1g18Qi0xaFtKyGq71Wx2uUbPLeDddlymG7iSwzvg1/q1MH2p2rz U3zQ5k3uX/km0O1YYB5hmP6OM/PJTX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG7JQhrLH5KSJ0= Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:42:37 -0000 Many thanks. I'm going to sit on this document until the updated lsp-attribute-ro comes out so that they can proceed together. Adrian > -----Original Message----- > From: Dongjie (Jimmy) [mailto:jie.dong@huawei.com] > Sent: 23 January 2015 02:44 > To: adrian@olddog.co.uk; Lou Berger > Cc: teas@ietf.org > Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt > > Dear Adrian, Lou and all, > > This revision adds the rules of using ERO Hop Attributes subobject in the loopback > scenario. Your review and comments are always appreciated. > > Many thanks, > Jie > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Friday, January 23, 2015 10:26 AM > > To: i-d-announce@ietf.org > > Cc: teas@ietf.org > > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Traffic Engineering Architecture and Signaling > > Working Group of the IETF. > > > > Title : GMPLS RSVP-TE Extensions for Lock Instruct and > > Loopback > > Authors : Jie Dong > > Mach(Guoyi) Chen > > Zhenqiang Li > > Daniele Ceccarelli > > Filename : draft-ietf-teas-rsvp-te-li-lb-03.txt > > Pages : 8 > > Date : 2015-01-22 > > > > Abstract: > > This document specifies extensions to Resource Reservation Protocol- > > Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and > > Loopback (LB) mechanisms for Label Switched Paths (LSPs). These > > mechanisms are applicable to technologies which use Generalized > > Multi-Protocol Label Switching (GMPLS) as control plane. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-03 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Jan 23 15:17:05 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB621A6ED8; Fri, 23 Jan 2015 15:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 g60khSLn5ATu; Fri, 23 Jan 2015 15:17:03 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D011A3BA9; Fri, 23 Jan 2015 15:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2801; q=dns/txt; s=iport; t=1422055023; x=1423264623; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PkobuTjStm1NoqzuTV1RAuiVbj5/6JJWXGq/amSDjAY=; b=Ap8KD7csOaPosNrb8cR5rqPeDR7NkQ6Og7xUhJRSoJdD3Wft0efY4kMc JB/YmGBl7vor6sx4HWskyBx4nd//GF1qruIoihF+ULMKoD4DjpA//hKhI FnbzAxwBI4eCiHXVSIWTLuG5Poyn0d3AZVaCMoH/qYXYzShiv1l5Cc5OX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFABPVwlStJA2B/2dsb2JhbABagwaBL8w7AoEVQwEBAQEBfYQNAgQ6PxIBCDZCJQEBBA4FiCzScQEBAQEBAQEBAQEBAQEBAQEBAQEZj00rB4QpBY5siSGBFYJ/jigig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,456,1418083200"; d="scan'208";a="390342525" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jan 2015 23:17:02 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0NNH2Ja021560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 23:17:02 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 17:17:01 -0600 From: "Rakesh Gandhi (rgandhi)" To: "adrian@olddog.co.uk" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" Thread-Topic: AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiABGh5+A Date: Fri, 23 Jan 2015 23:17:01 +0000 Message-ID: In-Reply-To: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> 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.218.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 23:17:04 -0000 Thank you Adrian for the thorough review. Please see replies inline .. .. On 2015-01-22 9:37 AM, "Adrian Farrel" wrote: >Thanks for this document which I found clear and not too long. Thank you. > >I have done my usual AD review to try to flush out any issues that >might otherwise show up in IETF last call or IESG review. > >The only largish issue I have is about error conditions. Pretty much the >only error handling I see is in 5.3 where you have: > > An egress node, upon receiving a Path message containing an > ASSOCIATION or Extended ASSOCIATION Object with Association Type set > to "Single Sided Associated Bidirectional LSP" MUST create an LSP in > the reverse direction or reject the Path message by sending a > PathErr. > >...but you don't say what reason code to give. > > Ack, please see below. > > >You need to handle some other error conditions such as... > >**** race conditions >**** what if the association is triggered by both ends at the same time? > > For double sided provisioning, this is expected and may not >necessary be an error. For single sided provisioning, this should not >happen given egress node only triggers reverse LSP as a response to the >incoming LSP. > >**** what if the reverse dirn LSP has already been associated with >something else? > > This can happen when an LSP on one side is being rerouted, and may >not necessarily be an error condition. For example, during MBB, there >will be two LSPs and association may be updated at some time during the >MBB process. > >**** failure conditions >**** what if not willing or able to associate? > > It is a bit difficult to know if this is really an error or it is a >transient condition due to LSP reroute or while node is being >provisioned, or there is provisioning error, etc. In such cases, >bidirectional LSP state would stay down so there should not any effect on >traffic. > > >**** what if set-up of reverse LSP fails? >**** what if requested REVERSE LSP parameters are not acceptable? > > > These are for single sided provisioning, right? For both of the >above cases, we can add a new PathErr ("LSP Admission Failure/Reverse LSP >Failure". Operator needs to then check the egress node as reverse LSP >failure could be for many different reasons. If you agree, we can add a >new PathErr code in the document (Reverse LSP Failure). > > >**** what if the remote end point doesn't support the association >mechanism defined here? how will the initiator know? > > An egress node may send PathErr ("LSP Admission Failure/Bad >Association Type" [RFC4872]. We can add it in the document if you agree. > > > =20 Thanks, Rakesh From nobody Sat Jan 24 07:23:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6861A1DBC; Sat, 24 Jan 2015 07:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Z46DwgXMSoBD; Sat, 24 Jan 2015 07:23:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155501A1BF5; Sat, 24 Jan 2015 07:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9980; q=dns/txt; s=iport; t=1422113022; x=1423322622; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hNXSJ7EO1LQWSMwsPKDTqwgx3LEIqSfHdT6pZrkz+Io=; b=ERLKpk15n1uNvf0QMvDvA0lH6sP8m63xztOohlCVJr3fkCWEgWwxz00p dQseCbSZK3k/DHi0Ou+NMowaWC3oIYW7sg9+fWXjoewVwO+wbLhQG8SkJ f6uTVNFEicIdL1XDwE1QilKDdIRYWL5iLuPhni15C1QtWyyaYZWgsZS6E Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAKq4w1StJA2K/2dsb2JhbABagwaBKwTMPwKBD0MBAQEBAX2EDQIEOj8SAQg2QiUBAQQOBYgs0hoBAQEBAQEBAQEBAQEBAQEBAQEaig6FCBEBJSsHAoQnBY5uiSGBFYJ/gkGFNIJ2gz0ig25vgQIJFwQefgEBAQ X-IronPort-AV: E=Sophos;i="5.09,460,1418083200"; d="scan'208";a="117229273" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 24 Jan 2015 15:23:41 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0OFNf6l011022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 24 Jan 2015 15:23:41 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sat, 24 Jan 2015 09:23:40 -0600 From: "Rakesh Gandhi (rgandhi)" To: "adrian@olddog.co.uk" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" Thread-Topic: AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiABoSkuA Date: Sat, 24 Jan 2015 15:23:40 +0000 Message-ID: In-Reply-To: <049b01d03650$f6300490$e2900db0$@olddog.co.uk> 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.218.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 15:23:44 -0000 Thank you Adrian for your detailed review comments. Please see inline .. .. On 2015-01-22 9:37 AM, "Adrian Farrel" wrote: >Authors, > =20 >Thanks for this document which I found clear and not too long. > >I have done my usual AD review to try to flush out any issues that >might otherwise show up in IETF last call or IESG review. > >The only largish issue I have is about error conditions. Pretty much the >only error handling I see is in 5.3 where you have: > > An egress node, upon receiving a Path message containing an > ASSOCIATION or Extended ASSOCIATION Object with Association Type set > to "Single Sided Associated Bidirectional LSP" MUST create an LSP in > the reverse direction or reject the Path message by sending a > PathErr. > >...but you don't say what reason code to give. > >You need to handle some other error conditions such as... > >**** race conditions >**** what if the association is triggered by both ends at the same time? >**** what if the reverse dirn LSP has already been associated with > something else? > >**** failure conditions >**** what if not willing or able to associate? >**** what if set-up of reverse LSP fails? >**** what if requested REVERSE LSP parameters are not acceptable? >**** what if the remote end point doesn't support the association > > mechanism defined here? how will the initiator know? Please refer to another email thread to address this comment. > > >I also have some smaller points as set out below. > >I'll put the I-D into "revised I-D needed" state while we discuss these >points and while you produce an update. > >Thanks for the work, >Adrian > >=3D=3D=3D=3D > >You have a different number of font-page authors and names in the >Authors' Addresses section. > >Looks like Fan Yang and Weilian Jiang should be moved to a >Contributors section. Fixed. FYI, I also fixed WG from CCAMP to TEAS at the top. > >--- > >Section 1 is OK, but it would have been better to just list the relevant >requirements (7, 11, 12, 50) and then the additional requirement (14). > >Probably no need to change now, but my preference is to avoid the risk >of introducing an error during the copying or editorial process. If you >feel like making this change, I would be happier. Find it easier to read the document when this text is in the same document. Prefer to keep it:) > >--- > >Because you use RBNF in section 4, you need to add a statement to >Section 2 like: > > This document uses the Routing Backus-Naur Form (RBNF) to define > message formats as defined in [RFC5511]. > >And then, of course, add a normative reference. Added. > >--- > >I think 2.1.1 is missing an important statement about co-routing. > >"A pair of reverse unidirectional LSPs that are associated to form an >associated bidirectional LSP do not necessarily follow the same path >through the network. If they do follow the same path, they are known as >'co-routed'." Saw the email exchange with Lou. Thanks Lou. I am assuming we are keeping the text as is. Note that this document does not discuss anything about co-routed LSPs. > >--- > >3.1 > > This section provides an overview and definition of the models for > provisioning bidirectional LSPs. > >This is missing the word "associated" to read "associated bidirectional" Added. > >--- > >Shouldn't 3.1.1 also mention the REVERSE_LSP Object. Something like... > > For the single sided provisioning, the Traffic Engineering (TE) > tunnel is configured only on one endpoint. An LSP for this tunnel is > initiated by the initiating endpoint with the (Extended) ASSOCIATION > Object inserted in the Path message. The other endpoint then creates > the corresponding reverse TE tunnel and signals the reverse LSP in > response using information from the REVERSE_LSP Object if present. Yes, added. > >--- > >3.1.2 > >Pedantry, but... > >OLD > For the double sided provisioning, two unidirectional TE tunnels are > configured independently on both endpoints. >NEW > For the double sided provisioning, two unidirectional TE tunnels are > configured independently, one on each endpoint. >END Added.=20 > >--- > >3.2 > > This section provides an overview of the association signaling > methods for the bidirectional LSPs. > >Again, this is missing "associated" Added. > >--- > >3.2.1 > >OLD > LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted > in the Path message, in which the Association Type indicating single > sided provisioning. >NEW > LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted > in the Path message, in which the Association Type indicating single > sided provisioning is included. >END Fixed. > >--- > >3.2.2 > >OLD > For the double sided provisioning model, both LSP1 and LSP2 are > signaled independently with (Extended) ASSOCIATION Object inserted in > the Path message, in which the Association Type indicating double > sided provisioning. >NEW > For the double sided provisioning model, both LSP1 and LSP2 are > signaled independently with (Extended) ASSOCIATION Object inserted in > the Path message, in which the Association Type indicating double > sided provisioning is included. Fixed. > >--- > >3.2.2 needs to include some comment about how the two LSPs are selected >to be associated. I think this is simply "by management action applied >at both end points", although I wonder whether it is enough to apply the >action at just one end point because the association object will achieve >the desired result. > >Please think about this and add a note. This is somewhat in Section 3.1.2. We could add something like: The LSPs to be selected for association are provisioned by the management action applied at both endpoints. > >--- > >Section 3.3.1 is fine as it is, but I think that it makes it look like >the REVERSE LSP object is only used for asymmetric b/w. Perhaps... > >OLD > As > described in this document, addition of the REVERSE_LSP Object also > allows the initiating node to control the reverse LSP by including > other existing objects in a REVERSE_LSP Object. >NEW > As > described in Section 4.4, addition of the REVERSE_LSP Object also > allows the initiating node to control other aspects of the reverse > LSP (such as its path) by including other subobjects in a REVERSE_LSP > Object. >END Fixed. > >--- > >For clarity 3.4 needs to observe that multiple association objects may >be present in the signaling of a single LSP. Adding following: An LSP MAY signal multiple (Extended) ASSOCIATION Objects with different Association Types. > >--- > >4.2 > > The new Association Types are defined as follows (values are > temporary early allocations as per RFC7120): > >Delete the bit in brackets, please, so that we don't accidentally find >it in the published RFC. Your message is already in 6.1 (which is good). Fixed. > =20 >--- > >4.4.1 > > Class_Num =3D 203 (of the form 11bbbbbb), C_Type =3D 1 (values are > temporary early allocations as per RFC7120) > >Same thing. Please remove the bit about early allocation. > >(BTW, you have "of the form 11bbbbbb" twice in this section. Fixe both. > >--- > >4.4.2 or 5.2 > >Maybe... > > The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object. Added in Section 5.2. > >--- > >5.2 > > An > egress node MUST tear down and reestablish a new reverse LSP when > REVERSE_LSP Object is either added or removed in the received Path > message. > >That's confusing! >- Why is modification of an existing LSP not allowed? >- Why does removal of the REVERSE_LSP object require tearing down and > reestablishment since all that has happened is that the requirements > for the reverse LSP have been relaxed? >- Why does addition of the REVERSE_LSP necessarily require tear down > and reestablishment when the existing LSP might already satisfy the > requirements? >- Is make-before-break used or is this assumed to be an out-of-service > operation? If out-of-service you need to describe how that is > achieved (e.g., using LI). Understand and agree with above comments. There are various scenarios where change may lead to in-place modification, MBB or setup and teardown (which may depend on implementation). How about something like following: An egress node MAY tear down and reestablish a new reverse LSP, or trigger re-optimization or in-place modification when REVERSE_LSP Object is either added or removed in the received Path message (which may depend on the local policy). > >--- > >5.3 has > > If REVERSE_LSP Object is not present in the received Path message of > the LSP, the egress node SHOULD use the LSP properties from the > received LSP Path message to signal the LSP in the reverse direction > (which may depend on the local policy). > >This worries me. Do you mean that in the absence of a REVERSE_LSP object >containing an ERO, the reverse LSP MUST be co-routed with the forward >LSP? > No. There will also be no (forward LSP) full ERO in the LSP either to do that. Does following work? =20 If REVERSE_LSP Object is not present in the received Path message of the LSP, the egress node MAY use the LSP properties from the received LSP Path message to signal the LSP in the reverse direction that MAY or MAY NOT follow the forward LSP path (which may depend on the local policy). Many thanks Adrian for the great review. Regards, Rakesh > From nobody Sun Jan 25 07:18:44 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D889F1A1A6C for ; Sun, 25 Jan 2015 07:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 jtvwyOwTVfhJ for ; Sun, 25 Jan 2015 07:18:41 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 6535F1A1A6B for ; Sun, 25 Jan 2015 07:18:41 -0800 (PST) Received: (qmail 31506 invoked by uid 0); 25 Jan 2015 15:18:38 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Jan 2015 15:18:38 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id kFJX1p0042SSUrH01FJa8a; Sun, 25 Jan 2015 08:18:38 -0700 X-Authority-Analysis: v=2.1 cv=VqmwXYGn c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=g6eH7H9jTIQA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=B9ntvlkMYQQA:10 a=YNv0rlydsVwA:10 a=AUd_NHdVAAAA:8 a=WoL-sOQpjPKGlilVdLQA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=kcvRHSwIOCHfkpvLfShs7rvbV5StHbW/AE6nOlSXwO0=; b=bXAwZ476nF5oRuMDEsBXyMSd+tt66YFQMz5ltwO7PZZbMxyBFe/n9C5XolgZdc3k8dYYMQUaXkHuhkGizQBVyvPUlflrPKjQHI32gFVugOhl4qQd+VhDBRuxfjb3Lkr0; Received: from [172.56.2.8] (port=55533 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YFOxK-0002jG-ON; Sun, 25 Jan 2015 08:18:31 -0700 From: Lou Berger To: "Rakesh Gandhi (rgandhi)" , , Date: Sun, 25 Jan 2015 10:18:29 -0500 Message-ID: <14b21ac25e8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <14b1ca3a288.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.12 (build: 21020012) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.2.8 authed with lberger@labn.net} Archived-At: Cc: "Alvaro Retana \(aretana\)" , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 15:18:43 -0000 HI Rakesh, A few comments below... On January 24, 2015 10:24:16 AM "Rakesh Gandhi (rgandhi)" wrote: > > > >I think 2.1.1 is missing an important statement about co-routing. > > > >"A pair of reverse unidirectional LSPs that are associated to form an > >associated bidirectional LSP do not necessarily follow the same path > >through the network. If they do follow the same path, they are known as > >'co-routed'." > > > Saw the email exchange with Lou. Thanks Lou. I am assuming we are > keeping the text as is. Right. ... > > > >For clarity 3.4 needs to observe that multiple association objects may > >be present in the signaling of a single LSP. > > Adding following: > An LSP MAY signal multiple (Extended) ASSOCIATION Objects with different > Association Types. > As this document does not define the Association object it is the wrong place to have its conformance language. That said, and informative statement is just fine. How about: As defined, see [RFC6780], multiple ASSOCIATION objects may be present in the signaling of a single LSP. > > > > >--- > > > >4.2 > > > > The new Association Types are defined as follows (values are > > temporary early allocations as per RFC7120): > > > >Delete the bit in brackets, please, so that we don't accidentally find > >it in the published RFC. Your message is already in 6.1 (which is good). > > Fixed. > > > > >--- > > > >4.4.1 > > > > Class_Num = 203 (of the form 11bbbbbb), C_Type = 1 (values are > > temporary early allocations as per RFC7120) > > > >Same thing. Please remove the bit about early allocation. > > > >(BTW, you have "of the form 11bbbbbb" twice in this section. > > Fixe both. > > > > >--- > > > >4.4.2 or 5.2 > > > >Maybe... > > > > The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object. > > Added in Section 5.2. > > > > >--- > > > >5.2 > > > > An > > egress node MUST tear down and reestablish a new reverse LSP when > > REVERSE_LSP Object is either added or removed in the received Path > > message. > > > >That's confusing! > >- Why is modification of an existing LSP not allowed? > >- Why does removal of the REVERSE_LSP object require tearing down and > > reestablishment since all that has happened is that the requirements > > for the reverse LSP have been relaxed? > >- Why does addition of the REVERSE_LSP necessarily require tear down > > and reestablishment when the existing LSP might already satisfy the > > requirements? > >- Is make-before-break used or is this assumed to be an out-of-service > > operation? If out-of-service you need to describe how that is > > achieved (e.g., using LI). > > > Understand and agree with above comments. There are various scenarios > where change may lead to in-place modification, MBB or setup and teardown > (which may depend on implementation). > > How about something like following: > An egress node MAY tear down and reestablish a new reverse LSP, or trigger > re-optimization or in-place modification when > REVERSE_LSP Object is either added or removed in the received Path > message (which may depend on the local policy). > > > > > >--- > > > >5.3 has > > > > If REVERSE_LSP Object is not present in the received Path message of > > the LSP, the egress node SHOULD use the LSP properties from the > > received LSP Path message to signal the LSP in the reverse direction > > (which may depend on the local policy). > > > >This worries me. Do you mean that in the absence of a REVERSE_LSP object > >containing an ERO, the reverse LSP MUST be co-routed with the forward > >LSP? > > > > > No. There will also be no (forward LSP) full ERO in the LSP either to > do that. > Does following work? > > If REVERSE_LSP Object is not present in the received Path message of > the LSP, the egress node MAY use the LSP properties from the > received LSP Path message to signal the LSP in the reverse direction > that MAY or MAY NOT follow the forward LSP path > (which may depend on the local policy). > Humm, I think we should dig into this a bit more before making this change. Adrian, Do you have a specific concern with the existing text that you would like to see addressed ? I think the proposed revision is even less helpful. Lou From nobody Sun Jan 25 09:38:57 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B761A872D; Sun, 25 Jan 2015 09:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9pPZfNBecPDI; Sun, 25 Jan 2015 09:38:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0931A8727; Sun, 25 Jan 2015 09:38:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150125173852.15201.30786.idtracker@ietfa.amsl.com> Date: Sun, 25 Jan 2015 09:38:52 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:38:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Manav Bhatia Lizhong Jin Filename : draft-ietf-teas-gmpls-lsp-fastreroute-01.txt Pages : 15 Date : 2015-01-25 Abstract: This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 25 09:44:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F013B1A872A for ; Sun, 25 Jan 2015 09:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XnNoQxTl8LD7 for ; Sun, 25 Jan 2015 09:44:32 -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 DB0BA1A8735 for ; Sun, 25 Jan 2015 09:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2481; q=dns/txt; s=iport; t=1422207871; x=1423417471; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VEYj1TMN53c0YjCbt/IyOJ4v+28daI02nPIV5YqB4G0=; b=NXctrfamk5blNOtDqCofB1ao85vNGe3w56uy/WVRJKahve94KJpeIXDc eJPbT344WRxlpKQj3GPlokYLiE5I5L5ErsAa/VukRAsQUyUmQ7gOJB0no dWza9uTf8Lf5J/Rn+14ahkz1yu+UKZYFnuFOrClP4VIP146jXu5XmHGKn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFADArxVStJA2E/2dsb2JhbABagwZSVAUExisMhW8CgQ9DAQEBAQF9hA0BAQQBAQE3NAsSAQgSJDcLFw4CBA4FCYgjCAXRbwEBAQEBAQEDAQEBAQEBAQEBGY9FMweEKQWNDYFhg0uFVoEVNoJJimuDPSKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,463,1418083200"; d="scan'208";a="387528540" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jan 2015 17:44:31 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0PHiUcI005803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 17:44:31 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 11:44:30 -0600 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-01.txt Thread-Index: AQHQOMXSfhSOVh3wTUqH0wKoz72MFJzRLFiA Date: Sun, 25 Jan 2015 17:44:29 +0000 Message-ID: In-Reply-To: <20150125173852.15201.30786.idtracker@ietfa.amsl.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.237.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <43975E810C7E7543B02C257F5620634D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky , "Nobo Akiya \(nobo\)" , Loa Andersson Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:44:34 -0000 Hi WG, This document is updated to address review comments from Nobo, Loa and Gregory. There are also few minor editorial changes. Welcome your review comments. Thanks, Rakesh On 2015-01-25 12:38 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Traffic Engineering Architecture and >Signaling Working Group of the IETF. > > Title : Extensions to Resource Reservation Protocol For >Fast Reroute of Traffic Engineering GMPLS LSPs > Authors : Mike Taillon > Tarek Saad > Rakesh Gandhi > Manav Bhatia > Lizhong Jin > Filename : draft-ietf-teas-gmpls-lsp-fastreroute-01.txt > Pages : 15 > Date : 2015-01-25 > >Abstract: > This document defines Resource Reservation Protocol - Traffic > Engineering (RSVP-TE) signaling extensions to support Fast Reroute > (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol > Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling > extensions allow the coordination of bidirectional bypass tunnel > assignment protecting a common facility in both forward and reverse > directions of a co-routed bidirectional LSP. In addition, these > extensions enable the re-direction of bidirectional traffic and > signaling onto bypass tunnels that ensure co-routedness of data and > signaling paths in the forward and reverse directions after FRR to > avoid RSVP soft-state timeout. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-gmpls-lsp-fastreroute-0= 1 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Sun Jan 25 09:46:15 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABF1A7016 for ; Sun, 25 Jan 2015 09:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FE1LqqU0dqbJ for ; Sun, 25 Jan 2015 09:46:08 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA381A7032 for ; Sun, 25 Jan 2015 09:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32740; q=dns/txt; s=iport; t=1422207968; x=1423417568; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=1oN56CBGtEp8roXEX2HZYIuNiApkkrJY50VJqpSOS2s=; b=XuVADfEAwPs2HEN4AJvpfZpPeYXziGiquNYEf3TPdzq8GFoQ2+s9lQ0S +2K/uY0EP6H8yLF3ABcgiy/KKJPj8K2HGwC7zlu97jqL2/tnyMUJxavhF AGOruRJfZ4s2+9+rjScfsR6g6pZXwZjXBC9HDhAvuO1CkBIhr0On/8gl2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAIAqxVStJV2P/2dsb2JhbABagkNDUlkEzCYCgQ9DAQEBAQF9hAwBAgQtTBIBCBEDAQIhAQYoERQJCAEBBAENBYgYAxHMYQ2FDwEBAQEBAQEBAQEBAQEBAQEBAQEBAReNToFZAQE+EQcGhCMFhUOHSoFhh1yBRYEVgn+CQYVxhXYig25vgQs5fgEBAQ X-IronPort-AV: E=Sophos;i="5.09,463,1418083200"; d="scan'208,217";a="390719671" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jan 2015 17:46:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0PHk7Bp013619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 17:46:07 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 11:46:06 -0600 From: "Rakesh Gandhi (rgandhi)" To: "Nobo Akiya (nobo)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" Thread-Topic: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggZC54oA Date: Sun, 25 Jan 2015 17:46:06 +0000 Message-ID: In-Reply-To: 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.237.148] Content-Type: multipart/alternative; boundary="_000_D0EA95B54D39Frgandhiciscocom_" MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:46:11 -0000 --_000_D0EA95B54D39Frgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Nobo for the detailed review comments. Have uploaded a new revision (01) to address these comments. Thanks again, Rakesh From: "Nobo Akiya (nobo)" > Date: Wednesday, 24 December, 2014 5:45 PM To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" > Cc: TEAS WG > Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Resent-From: > Resent-To: "frederic.jounay@orange.ch" >, "Lizhong com>"= >, >, "=3DSMTP:mtaillon@cisco. com" >, Rakesh Gandhi >, >, Zafar = Ali > Resent-Date: Wednesday, 24 December, 2014 5:46 PM Hi Authors, Happy Holidays! I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its WG= adoption poll), and had some questions/comments. Please find them below. 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be eas= ier to understand if =93list=94 is used. [OLD] The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object prior to adding the node's IP address in the node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding a Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding an IPv4 or IPv6 subobject. [NEW] When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object: o The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-ID subobject describing the node's IP address. o The Node-ID subobject MUST also be added. o The IPv4 or IPv6 subobject MUST also be added. 2) Section 4.4.1 - First sentence of the third paragraph was quite difficul= t to read/understand. Perhaps adding some commas and quotations may improve= its readability. [OLD] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject whose bypass tunnel and the node-ID subobject when used as a bypass tunnel source terminates locally assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. [NEW] The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT subobject, whose bypass tunnel and the node-ID subobject when used as a "bypass tunnel source" terminates locally, assigns the matching bidirectional bypass tunnel in the reverse direction, and forwards the RSVP Path message downstream. 3) Section 4.4.1 - I have a slight concern regarding below statement. [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT subobjects from multiple downstream PLRs, the decision of selecting a bypass tunnel in the reverse direction can be based on local policy, for example, prefer link protection versus node protection bypass tunnel, or prefer the most upstream versus least upstream node protection bypass tunnel. [snip] When LSRs within a bidirectional LSP employ different policies, as describe= d above, then we can result in pockets where there are no protections. For example: Node A uses node protection. Node B and C use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +-+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. Another example: Node A and C use node protection. Node B use link protection. +---------+ / +-+ \ / / \ \ / / v v A ----- B ----- C ^ / \ / +----------+ The result of above is that, in the reverse direction, there will not be an= y protection between nodes B and A. In both cases, if there is a breakage of the link connecting nodes A and B,= then node C receives the RSVP PATH message. If node C follows procedures d= escribed in Section 6.2, then it will not find a matching bypass tunnel. If I=92m off track, then I apologize for the noise. If above is indeed a pr= oblem, then this limitation should at least be described in the document, f= ollowed by a recommendation of all LSRs within a bidirectional tunnel emplo= ying the same policy. It may be possible to (be brave and) address this but it will require more = procedures. I=92ll leave the decision and further investigation to the auth= ors. 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? [snip] In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does not assign a bypass tunnel in the reverse direction. This allows the downstream PLR to always initiate the bypass assignment and upstream PLR to simply reflect the bypass assignment. [snip] I=92m guessing that there should be a SHOULD =85 5) Section 6.2 - =93If=94 and =93If not=94 in below text do not correspond = to each other (thus a bit confusing). [snip] - If found, checks whether the primary LSP traffic and signaling are already rerouted over the found bypass tunnel. If not, PRR R5 activates FRR reroute procedures to direct traffic and RSVP Resv over the found bypass tunnel T2 in the reverse direction. [snip] If we write above with a psuedocode, then it will be: if (bypass tunnel found) { // =93If found=94 is this line check if already rerouted if (not already rerouted) { // =93If not=94 is this line active FRR reroute } } It might make the texts easier to read/understand if you can rephrase it a= bit? Thanks! -Nobo --_000_D0EA95B54D39Frgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <16ECF093CE15A448B7987908194ACADA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thank you Nobo for the detailed review comments.

Have uploaded a new revision (01) to address these comments.

Thanks again,
Rakesh


From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Wednesday, 24 December, 2014 = 5:45 PM
To: "draft-tsaad-ccamp-r= svpte-bidir-lsp-fastreroute@tools.ietf.org" <draft-tsaad-= ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org>
Cc: TEAS WG <teas@ietf.org>
Subject: Mail regarding draft-tsaad= -ccamp-rsvpte-bidir-lsp-fastreroute
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: "frederic.jounay@orange.ch" <frederic.jounay@orange.ch>, &q= uot;Lizhong com>" <lizho.= jin@gmail.com>, <manav@ionosnetworks.com= >, "=3DSMTP:mtaillon@cisco. com" <mtaillon@cisco.com>, Rakesh Gandhi <rgandhi@cisco.com>, <tsaad@cisco.com>, Zafar Ali <zali@cisco.com>
Resent-Date: Wednesday, 24 December= , 2014 5:46 PM

Hi Authors,

 

Happy Holidays!

 

I read draft-tsaad-ccamp-rsv= pte-bidir-lsp-fastreroute-05 (as part of its WG adoption poll), and had som= e questions/comments. Please find them below.

 

 

1) Section 4.4.1 - The rules= for the BYPASS_ASSIGNMENT subobject may be easier to understand if =93list= =94 is used.

 

[OLD]

   The BYPASS_ASSI= GNMENT subobject is added in the RECORD_ROUTE object

   prior to adding= the node's IP address in the node-ID subobject.  A<= /p>

   node MUST NOT a= dd a BYPASS_ASSIGNMENT subobject without also adding a

   Node-ID subobje= ct.  A node MUST NOT add a BYPASS_ASSIGNMENT subobject

   without also ad= ding an IPv4 or IPv6 subobject.

 

[NEW]

   When the BYPASS= _ASSIGNMENT subobject is added in the RECORD_ROUTE

   object:

 

   o  The BYP= ASS_ASSIGNMENT subobject MUST be added prior to the node-ID

    &nbs= p; subobject describing the node's IP address.

 

   o  The Nod= e-ID subobject MUST also be added.

 

   o  The IPv= 4 or IPv6 subobject MUST also be added.

 

 

2) Section 4.4.1 - First sen= tence of the third paragraph was quite difficult to read/understand. Perhap= s adding some commas and quotations may improve its readability.=

 

[OLD]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject whose= bypass tunnel and the node-ID subobject when used as

   a bypass tunnel= source terminates locally assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

[NEW]

   The upstream PL= R (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject, whos= e bypass tunnel and the node-ID subobject when used as

   a "bypass = tunnel source" terminates locally, assigns the matching

   bidirectional b= ypass tunnel in the reverse direction, and forwards

   the RSVP Path m= essage downstream.

 

 

3) Section 4.4.1 - I have a = slight concern regarding below statement.

 

[snip]

   In the absence = of BYPASS_ASSIGNMENT subobject, the upstream PLR does

   not assign a by= pass tunnel in the reverse direction.  This allows the

   downstream PLR = to always initiate the bypass assignment and upstream

   PLR to simply r= eflect the bypass assignment.

 

   In the case of = upstream PLR receiving multiple BYPASS_ASSIGNMENT

   subobjects from= multiple downstream PLRs, the decision of selecting a

   bypass tunnel i= n the reverse direction can be based on local policy,

   for example, pr= efer link protection versus node protection bypass

   tunnel, or pref= er the most upstream versus least upstream node

   protection bypa= ss tunnel.

[snip]

 

When LSRs within a bidirecti= onal LSP employ different policies, as described above, then we can result = in pockets where there are no protections.

 

For example:

 

Node A uses node protection.=

Node B and C use link protec= tion.

 

    +---------+

   /       +-+ \=

  /       /   \ \

/       /     = v v

A ----- B ----- C

         ^  &n= bsp;  /

          \ &n= bsp; /

           = 3;-+

          &nbs= p;         

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

Another example:<= /span>

 

Node A and C use node protec= tion.

Node B use link protection.<= o:p>

 

    +---------+

   /       +-+ \=

  /       /   \ \

/       /     = v v

A ----- B ----- C

^          &nb= sp;   /

  \         &n= bsp;  /

   +----------+

 

The result of above is that,= in the reverse direction, there will not be any protection between nodes B= and A.

 

In both cases, if there is a= breakage of the link connecting nodes A and B, then node C receives the RS= VP PATH message. If node C follows procedures described in Section 6.2, the= n it will not find a matching bypass tunnel.

 

If I=92m off track, then I a= pologize for the noise. If above is indeed a problem, then this limitation = should at least be described in the document, followed by a recommendation = of all LSRs within a bidirectional tunnel employing the same policy.

 

It may be possible to (be br= ave and) address this but it will require more procedures. I=92ll leave the= decision and further investigation to the authors.

 

 

4) Section 4.4.1 - Should th= ere be SHOULD or MUST in this paragraph?

 

[snip]

   In the absence of BYPASS_ASSIGNMENT = subobject, the upstream PLR does

   not assign a bypass tunnel in the re= verse direction.  This allows the

   downstream PLR to always initiate th= e bypass assignment and upstream

   PLR to simply reflect the bypass ass= ignment.

[snip]

 

I=92m guessing that there should be a SHOULD =85<= o:p>

 

 

5) Section 6.2 - =93If=94 and =93If not=94 in bel= ow text do not correspond to each other (thus a bit confusing).<= /p>

 

[snip]

      - If found, checks= whether the primary LSP traffic and signaling

        are al= ready rerouted over the found bypass tunnel.  If not, PRR

        R5 act= ivates FRR reroute procedures to direct traffic and

        RSVP R= esv over the found bypass tunnel T2 in the

        revers= e direction.

[snip]

 

If we write above with a psuedocode, then it will= be:

 

&nbs= p;   if (bypass tunnel found) {      // = =93If found=94 is this line

&nbs= p;       check if already rerouted=

&nbs= p;       if (not already rerouted) { // =93If= not=94 is this line

&nbs= p;            active= FRR reroute

&nbs= p;       }

&nbs= p;   }

 

It  might make the texts easier to read/unde= rstand if you can rephrase it a bit?

 

 

Thanks!

 

-Nobo

 

 --_000_D0EA95B54D39Frgandhiciscocom_-- From nobody Sun Jan 25 09:47:57 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13C1A873B for ; Sun, 25 Jan 2015 09:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Z5At4Cw5_5Hy for ; Sun, 25 Jan 2015 09:47:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886FD1A7032 for ; Sun, 25 Jan 2015 09:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8332; q=dns/txt; s=iport; t=1422208071; x=1423417671; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=D32KVyPmDUWuFZaZcpLilqgiNHk3MHk7qbDz5BGdEnA=; b=iNF9tTQP1um8kUbuBiOqPr+on9SVwjTkadQV47ya2+f42XW97rUikzfK O3OWNl0f6nVKPgINEanxNIb1onXpjTH9DSw+uD8WSfZwsdok24jAfyy/0 LGkpZ5OPpzfoV+jiLIjO6DrghG/A/oIuYG7ycyuiBssT4+GUtV3mn6Iqg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFAKMrxVStJA2D/2dsb2JhbABagwZSWQTGKwqFcQKBD0MBAQEBAX2EDAEBAQMBAQEBaAMLDgQBCBEDAQIBJyIGBgsUCQgBAQQBDQWIGAMJCA3MUg2FDwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI1KgUgQAgEcMwcGhCMFhUOHSoFhh1yBRYEVgn+CQYVxgjmDPSKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,463,1418083200"; d="scan'208";a="390653839" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2015 17:47:51 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0PHlorY001965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 17:47:50 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 11:47:50 -0600 From: "Rakesh Gandhi (rgandhi)" To: Loa Andersson , "Nobo Akiya (nobo)" , "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org" Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6AABXMfIAGJ7VwAA== Date: Sun, 25 Jan 2015 17:47:49 +0000 Message-ID: In-Reply-To: <549B978B.6080603@pi.nu> 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.237.148] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1383331F48597F429EB82979A594EA33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:47:54 -0000 Thank you Loa for the review. FYI: Have uploaded a new revision (01) to address the comments from Nobo. Thanks again, Rakesh On 2014-12-24 11:50 PM, "Loa Andersson" wrote: >Working Group, > >I was almost through my review of this document, saw Nobo's review >and found that he had found everything I found and a bit more :). > >With that and with Rakesh's statement that the comments will be >addressed I souppor the adoption of the document as a wg doc. > >/Loa > >On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >> Thank you Nobo for your detailed review comments. >> >> We will address these in the next revision. >> >> Happy holidays. >> >> Thanks, >> Rakesh >> >> >> From: "Nobo Akiya (nobo)" > >> Date: Wednesday, 24 December, 2014 5:45 PM >> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >> " >> > > >> Cc: TEAS WG > >> Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> Resent-From: > > >> Resent-To: "frederic.jounay@orange.ch >> " > >, "Lizhong com>" > >, > >, "=3DSMTP:mtaillon@cisco. com" >> >, Rakesh Gandhi >> >, > >, Zafar Ali > > >> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >> >> Hi Authors, >> >> Happy Holidays! >> >> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its >> WG adoption poll), and had some questions/comments. Please find them >>below. >> >> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be >> easier to understand if =B3list=B2 is used. >> >> [OLD] >> >> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object >> >> prior to adding the node's IP address in the node-ID subobject. A >> >> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding >>a >> >> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >>subobject >> >> without also adding an IPv4 or IPv6 subobject. >> >> [NEW] >> >> When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >> >> object: >> >> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >>node-ID >> >> subobject describing the node's IP address. >> >> o The Node-ID subobject MUST also be added. >> >> o The IPv4 or IPv6 subobject MUST also be added. >> >> 2) Section 4.4.1 - First sentence of the third paragraph was quite >> difficult to read/understand. Perhaps adding some commas and quotations >> may improve its readability. >> >> [OLD] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject whose bypass tunnel and the node-ID subobject when used as >> >> a bypass tunnel source terminates locally assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and forwards >> >> the RSVP Path message downstream. >> >> [NEW] >> >> The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT >> >> subobject, whose bypass tunnel and the node-ID subobject when used >>as >> >> a "bypass tunnel source" terminates locally, assigns the matching >> >> bidirectional bypass tunnel in the reverse direction, and forwards >> >> the RSVP Path message downstream. >> >> 3) Section 4.4.1 - I have a slight concern regarding below statement. >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does >> >> not assign a bypass tunnel in the reverse direction. This allows >>the >> >> downstream PLR to always initiate the bypass assignment and upstream >> >> PLR to simply reflect the bypass assignment. >> >> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >> >> subobjects from multiple downstream PLRs, the decision of selecting >>a >> >> bypass tunnel in the reverse direction can be based on local policy, >> >> for example, prefer link protection versus node protection bypass >> >> tunnel, or prefer the most upstream versus least upstream node >> >> protection bypass tunnel. >> >> [snip] >> >> When LSRs within a bidirectional LSP employ different policies, as >> described above, then we can result in pockets where there are no >> protections. >> >> For example: >> >> Node A uses node protection. >> >> Node B and C use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +-+ >> >> The result of above is that, in the reverse direction, there will not be >> any protection between nodes B and A. >> >> Another example: >> >> Node A and C use node protection. >> >> Node B use link protection. >> >> +---------+ >> >> / +-+ \ >> >> / / \ \ >> >> / / v v >> >> A ----- B ----- C >> >> ^ / >> >> \ / >> >> +----------+ >> >> The result of above is that, in the reverse direction, there will not be >> any protection between nodes B and A. >> >> In both cases, if there is a breakage of the link connecting nodes A and >> B, then node C receives the RSVP PATH message. If node C follows >> procedures described in Section 6.2, then it will not find a matching >> bypass tunnel. >> >> If I=B9m off track, then I apologize for the noise. If above is indeed a >> problem, then this limitation should at least be described in the >> document, followed by a recommendation of all LSRs within a >> bidirectional tunnel employing the same policy. >> >> It may be possible to (be brave and) address this but it will require >> more procedures. I=B9ll leave the decision and further investigation to >> the authors. >> >> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >> >> [snip] >> >> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does >> >> not assign a bypass tunnel in the reverse direction. This allows >>the >> >> downstream PLR to always initiate the bypass assignment and upstream >> >> PLR to simply reflect the bypass assignment. >> >> [snip] >> >> I=B9m guessing that there should be a SHOULD =8A >> >> 5) Section 6.2 - =B3If=B2 and =B3If not=B2 in below text do not correspo= nd to >> each other (thus a bit confusing). >> >> [snip] >> >> - If found, checks whether the primary LSP traffic and signaling >> >> are already rerouted over the found bypass tunnel. If not, PRR >> >> R5 activates FRR reroute procedures to direct traffic and >> >> RSVP Resv over the found bypass tunnel T2 in the >> >> reverse direction. >> >> [snip] >> >> If we write above with a psuedocode, then it will be: >> >> if (bypass tunnel found) { // =B3If found=B2 is this line >> >> check if already rerouted >> >> if (not already rerouted) { // =B3If not=B2 is this line >> >> active FRR reroute >> >> } >> >> } >> >> It might make the texts easier to read/understand if you can rephrase >> it a bit? >> >> Thanks! >> >> -Nobo >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Jan 25 09:51:00 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FB01A8748 for ; Sun, 25 Jan 2015 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7PPl5tXrOojl for ; Sun, 25 Jan 2015 09:50:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26831A873B for ; Sun, 25 Jan 2015 09:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44828; q=dns/txt; s=iport; t=1422208252; x=1423417852; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Zlz/I53jhY/UzIO5QDPRRdHfRciQeAOSVe7p+1YRB7k=; b=iLdONpCE2mScCmeanBTFzCN87Isf6H10bWN17e1ia/QRiKPTshjPp83M m4hczRQfiFX1wChNpH+X/44OLZIs2haPLYZHqtyiaJKpTjIyy+lC/lnAN /OUC13eroQEI7Y/go8ksSXjzfwf0pESJLYpSjqq8/dV98KZecxfLBJbrX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAF0sxVStJA2E/2dsb2JhbABagkNDUlkExhIZAQmFcQKBD0MBAQEBAX2EDAEBAQMBAQEBFxMaJAMLBQcCBAEIEQMBAQEBIAEGIgYGCxQJCAIEDgWIGAMJCA3Cf4lSDYUPAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEjUqBSBACASMBBxMNBAcGhCMFhUMshx6BYYVYggSBRYEVgn+CQYU0PYI5gz0ig25vAQGBQn4BAQE X-IronPort-AV: E=Sophos;i="5.09,464,1418083200"; d="scan'208,217";a="390639106" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jan 2015 17:50:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0PHonEx008848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 17:50:49 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 11:50:48 -0600 From: "Rakesh Gandhi (rgandhi)" To: Gregory Mirsky Thread-Topic: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute Thread-Index: AdAfw4yPXwLBG3MFToqlKPshDlwAggAFdR6AABXMfIAABlTzgAJ11UUAAAxUN4D//7OagIAEt5KAgBiPYAA= Date: Sun, 25 Jan 2015 17:50:48 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8CD918@eusaamb103.ericsson.se> 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.237.148] Content-Type: multipart/alternative; boundary="_000_D0EA968F4D3AArgandhiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Mike Taillon \(mtaillon\)" , Manav Bhatia , "frederic.jounay@orange.ch" , TEAS WG , "Lizhong com>" , "Tarek Saad \(tsaad\)" , "Zafar Ali \(zali\)" Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 17:50:56 -0000 --_000_D0EA968F4D3AArgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Gregory for your detailed review comments. Please see inline. .. From: Gregory Mirsky > Date: Friday, 9 January, 2015 4:47 PM To: Rakesh Gandhi > Cc: TEAS WG >, "Tarek Saad (tsaad)" >, "Lizhong com>" >, "=3DSMTP:mtaillon@cisco. com" >, Zafar Ali >, Manav Bhatia >, "frederic.jounay@orange.ch" > Subject: RE: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Rakesh, apologies for the delay. In place of "protection switchover in both directions" perhaps "protection = of bi-directional co-routed LSPs" may be used. Added text in the new revision =9601. And couple other questions: * section Behavior Post Link Failure To Re-coroute describes actions at= R5 as finds =85 if (found) =85 =85 But there's no discussion of what happens if "the bypass tunnel in the reve= rse direction that terminates on the Downstream PLR R3" cannot be found. Wo= uld such tunnel be signaled then? Yes, added text in the new revision =9601. * revertive actions are not discussed in the document. I think they sho= uld be discussed as support of revertive and non-revertive behaviors is req= uired for MPLS-TP networks. Ack, to be added in the next update. thanks again, Rakesh Regards, Greg -----Original Message----- From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] Sent: Tuesday, January 06, 2015 6:45 PM To: Gregory Mirsky Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); Zaf= ar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute Hi Gregory, Thank you for the context. Good stuff. May be we could state in the draft something along the line of: "PSC (RFC6378) is applicable to FRR (RFC4090) for local protection switchov= er in both directions in order to minimize traffic disruptions. In the abse= nce of such mechanism, control plane restoration proposed is required in or= der to avoid soft state time out". Would that work? thanks, Rakesh On 2015-01-06 9:18 PM, "Gregory Mirsky" > wrote: >Hi Rakesh, >thank you for your interest in my comments. >I can note that during work on MPLS-TP we, as union of MPLS and CCAMP >WGs, left question of RSVP FRR applicability undocumented. Perhaps we >can find mailing list discussions where some of us agreed that local >protection of uni-directional and bi-directional associated LSPs in >MPLS-TP can follow RFC 4090 but question of local protection of >bi-directional co-routed LSPs requires further discussion. And there >already were references to use ASSOCIATION object to support segment >protection if node protection desired. That would allow monitoring of >both working and protecting paths and switchover coordination by using >RFC 6378. >Of course, proposed mechanism is workable as control plane restoration >mechanism but I'm not convinced that is what should be standardized as >local protection mechanism. > > Regards, > Greg > >-----Original Message----- >From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com] >Sent: Tuesday, January 06, 2015 5:26 PM >To: Gregory Mirsky >Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); >Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch >Subject: Re: [Teas] Mail regarding >draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute > >Hi Gregory, > >Thank you for your review comments. > >Can u please elaborate how does segment protection using ASSOCIATION >object solve the highlighted issue ? I am thinking such mechanisms >would apply to FRR as well. > >Thanks, >Rakesh > > >On 2014-12-25 2:51 AM, "Gregory Mirsky" > >wrote: > >>Dear All, >>I think that node protection mode for bidirectional co-routed LSP FRR >>is cumbersome and, at best, likely cause out-of-order delivery and >>more service disruption (switching reverse direction on R5 from R4 >>onto R3 triggered by tunneled RSVP Path message). I believe that >>extension of RFC >>4090 for bidirectional co-routed LSP FRR is viable only for link >>protection mode and node protection must be referred to segment >>protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689). >>Without such change in the scope of the draft I cannot support its >>adoption by the WG. >> >> Regards, >> Greg >> >>-----Original Message----- >>From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson >>Sent: Wednesday, December 24, 2014 8:50 PM >>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo); >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>Cc: TEAS WG >>Subject: Re: [Teas] Mail regarding >>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >> >>Working Group, >> >>I was almost through my review of this document, saw Nobo's review and >>found that he had found everything I found and a bit more :). >> >>With that and with Rakesh's statement that the comments will be >>addressed I souppor the adoption of the document as a wg doc. >> >>/Loa >> >>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote: >>> Thank you Nobo for your detailed review comments. >>> >>> We will address these in the next revision. >>> >>> Happy holidays. >>> >>> Thanks, >>> Rakesh >>> >>> >>> From: "Nobo Akiya (nobo)" >> >>> Date: Wednesday, 24 December, 2014 5:45 PM >>> To: "draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute@tools.ietf.org >>> " >>> >>> >> g >>> > >>> > >>> Cc: TEAS WG >> >>> Subject: Mail regarding >>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute >>> Resent-From: >>> > >>> Resent-To: "frederic.jounay@orange.ch >>>" >>>>, "Lizhong com>" >>> >>, >>>>>, >>>"=3DSMTP:mtaillon@cisco. com" >>> >>, Rakesh Gandhi >>>>>, >>>>, Zafar Ali >>>> >>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM >>> >>> Hi Authors, >>> >>> Happy Holidays! >>> >>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of >>>its WG adoption poll), and had some questions/comments. Please find >>>them below. >>> >>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may >>> be easier to understand if "list" is used. >>> >>> [OLD] >>> >>> The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE >>> object >>> >>> prior to adding the node's IP address in the node-ID subobject. >>> A >>> >>> node MUST NOT add a BYPASS_ASSIGNMENT subobject without also >>> adding a >>> >>> Node-ID subobject. A node MUST NOT add a BYPASS_ASSIGNMENT >>> subobject >>> >>> without also adding an IPv4 or IPv6 subobject. >>> >>> [NEW] >>> >>> When the BYPASS_ASSIGNMENT subobject is added in the >>> RECORD_ROUTE >>> >>> object: >>> >>> o The BYPASS_ASSIGNMENT subobject MUST be added prior to the >>> node-ID >>> >>> subobject describing the node's IP address. >>> >>> o The Node-ID subobject MUST also be added. >>> >>> o The IPv4 or IPv6 subobject MUST also be added. >>> >>> 2) Section 4.4.1 - First sentence of the third paragraph was quite >>> difficult to read/understand. Perhaps adding some commas and >>> quotations may improve its readability. >>> >>> [OLD] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a bypass tunnel source terminates locally assigns the matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> [NEW] >>> >>> The upstream PLR (downstream MP) that detects a >>> BYPASS_ASSIGNMENT >>> >>> subobject, whose bypass tunnel and the node-ID subobject when >>> used as >>> >>> a "bypass tunnel source" terminates locally, assigns the >>> matching >>> >>> bidirectional bypass tunnel in the reverse direction, and >>> forwards >>> >>> the RSVP Path message downstream. >>> >>> 3) Section 4.4.1 - I have a slight concern regarding below statement. >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT >>> >>> subobjects from multiple downstream PLRs, the decision of >>> selecting a >>> >>> bypass tunnel in the reverse direction can be based on local >>> policy, >>> >>> for example, prefer link protection versus node protection >>> bypass >>> >>> tunnel, or prefer the most upstream versus least upstream node >>> >>> protection bypass tunnel. >>> >>> [snip] >>> >>> When LSRs within a bidirectional LSP employ different policies, as >>> described above, then we can result in pockets where there are no >>> protections. >>> >>> For example: >>> >>> Node A uses node protection. >>> >>> Node B and C use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +-+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> Another example: >>> >>> Node A and C use node protection. >>> >>> Node B use link protection. >>> >>> +---------+ >>> >>> / +-+ \ >>> >>> / / \ \ >>> >>> / / v v >>> >>> A ----- B ----- C >>> >>> ^ / >>> >>> \ / >>> >>> +----------+ >>> >>> The result of above is that, in the reverse direction, there will >>> not be any protection between nodes B and A. >>> >>> In both cases, if there is a breakage of the link connecting nodes A >>> and B, then node C receives the RSVP PATH message. If node C follows >>> procedures described in Section 6.2, then it will not find a >>> matching bypass tunnel. >>> >>> If I'm off track, then I apologize for the noise. If above is indeed >>> a problem, then this limitation should at least be described in the >>> document, followed by a recommendation of all LSRs within a >>> bidirectional tunnel employing the same policy. >>> >>> It may be possible to (be brave and) address this but it will >>> require more procedures. I'll leave the decision and further >>> investigation to the authors. >>> >>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph? >>> >>> [snip] >>> >>> In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR >>> does >>> >>> not assign a bypass tunnel in the reverse direction. This >>> allows the >>> >>> downstream PLR to always initiate the bypass assignment and >>> upstream >>> >>> PLR to simply reflect the bypass assignment. >>> >>> [snip] >>> >>> I'm guessing that there should be a SHOULD ... >>> >>> 5) Section 6.2 - "If" and "If not" in below text do not correspond >>> to each other (thus a bit confusing). >>> >>> [snip] >>> >>> - If found, checks whether the primary LSP traffic and >>> signaling >>> >>> are already rerouted over the found bypass tunnel. If not, >>> PRR >>> >>> R5 activates FRR reroute procedures to direct traffic and >>> >>> RSVP Resv over the found bypass tunnel T2 in the >>> >>> reverse direction. >>> >>> [snip] >>> >>> If we write above with a psuedocode, then it will be: >>> >>> if (bypass tunnel found) { // "If found" is this line >>> >>> check if already rerouted >>> >>> if (not already rerouted) { // "If not" is this line >>> >>> active FRR reroute >>> >>> } >>> >>> } >>> >>> It might make the texts easier to read/understand if you can >>> rephrase it a bit? >>> >>> Thanks! >>> >>> -Nobo >>> >>> >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> >> >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>Teas mailing list >>Teas@ietf.org >>https://www.ietf.org/mailman/listinfo/teas > --_000_D0EA968F4D3AArgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thank you Gregory for your detailed review comments.

Please see inline. <RG>..

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Friday, 9 January, 2015 4:47 = PM
To: Rakesh Gandhi <rgandhi@cisco.com>
Cc: TEAS WG <teas@ietf.org>, "Tarek Saad (tsaad)" <tsaad@cisco.com>, "Lizhong com&= gt;" <lizho.jin@gmail.com>, "=3DSMTP:mtaillon@cisco. com" <mtaillon@cisco.com>, Zafar Ali <zali@cisco.com>, Manav Bhatia <manav@ionosnetworks.com>, "frederic.jounay@orange.ch" <frederic.jounay@orange.ch= >
Subject: RE: [Teas] Mail regarding = draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

Hi Rakesh,
apologies for the delay.
In place of "protection switchover in both directions" perha= ps "protection of bi-directional co-routed LSPs" may be used.

<RG> Added text in the new revision =9601.

And couple other questions:
  • section Behavior Post Link Failure To Re-coroute describes actions at R= 5 as
finds =85
if (found) =85
   =85
But there's no discussion of what happens= if "the bypass tunnel in the reverse direction that terminates on the= Downstream PLR R3" cannot be found. Would such tunnel be signaled the= n?

<RG> Yes, added text in the new revision =9601.

  • revertive actions are not discussed in the document. I think they shoul= d be discussed as support of revertive and non-revertive behaviors is requi= red for MPLS-TP networks.

<RG> Ack, to be added in the next update.

thanks  again,
Rakesh

 

        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:= rgandhi@cisco.com]
Sent: Tuesday, January 06, 2015 6:45 PM
To: Gregory Mirsky
Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); = Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch<= br> Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastr= eroute
 
Hi Gregory,
 
Thank you for the context. Good stuff.
 
May be we could state in the draft something along the line of:
"PSC (RFC6378) is applicable to FRR (RFC4090) for local protectio= n switchover in both directions in order to minimize traffic disruptions. I= n the absence of such mechanism, control plane restoration proposed is requ= ired in order to avoid soft state time out".
 
Would that work?
 
thanks,
Rakesh
 
 
 
On 2015-01-06 9:18 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
wrote:
 
>Hi Rakesh,
>thank you for your interest in my comments.
>I can note that during work on MPLS-TP we, as union of MPLS and CC= AMP
>WGs, left question of RSVP FRR applicability undocumented. Perhaps= we
>can find mailing list discussions where some of us agreed that loc= al
>protection of uni-directional and bi-directional associated LSPs i= n
>MPLS-TP can follow RFC 4090 but question of local protection of
>bi-directional co-routed LSPs requires further discussion. And the= re
>already were references to use ASSOCIATION object to support segme= nt
>protection if node protection desired. That would allow monitoring= of
>both working and protecting paths and switchover coordination by u= sing
>RFC 6378.
>Of course, proposed mechanism is workable as control plane restora= tion
>mechanism but I'm not convinced that is what should be standardize= d as
>local protection mechanism.
>
>       Regards,
>           =     Greg
>
>-----Original Message-----
>From: Rakesh Gandhi (rgandhi) [mailto:rgandhi@cisco.com]
>Sent: Tuesday, January 06, 2015 5:26 PM
>To: Gregory Mirsky
>Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mt= aillon);
>Zafar Ali (zali); Manav Bhatia; frederic.jounay@orange.ch
>Subject: Re: [Teas] Mail regarding
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>
>Hi Gregory,
>
>Thank you for your review comments.
>
>Can u please elaborate how does segment protection using ASSOCIATI= ON
>object solve the highlighted issue ?  I am thinking such mech= anisms
>would apply to FRR as well.
>
>Thanks,
>Rakesh
>
>
>On 2014-12-25 2:51 AM, "Gregory Mirsky" <gregory.mirsky@ericsson.com>
>wrote:
>
>>Dear All,
>>I think that node protection mode for bidirectional co-routed = LSP FRR
>>is cumbersome and, at best, likely cause out-of-order delivery= and
>>more service disruption (switching reverse direction on R5 fro= m R4
>>onto R3 triggered by tunneled RSVP Path message). I believe th= at
>>extension of RFC
>>4090 for bidirectional co-routed LSP FRR is viable only for li= nk
>>protection mode and node protection must be referred to segmen= t
>>protection and use of RSVP ASSOCIATION object (RFC 4872 and RF= C 6689).
>>Without such change in the scope of the draft I cannot support= its
>>adoption by the WG.
>>
>>      Regards,
>>          &n= bsp;   Greg
>>
>>-----Original Message-----
>>From: Teas [mailto:te= as-bounces@ietf.org] On Behalf Of Loa Andersson
>>Sent: Wednesday, December 24, 2014 8:50 PM
>>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);
>>Cc: TEAS WG
>>Subject: Re: [Teas] Mail regarding
>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>
>>Working Group,
>>
>>I was almost through my review of this document, saw Nobo's re= view and
>>found that he had found everything I found and a bit more :).<= /div>
>>
>>With that and with Rakesh's statement that the comments will b= e
>>addressed I souppor the adoption of the document as a wg doc.<= /div>
>>
>>/Loa
>>
>>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote:
>>> Thank you Nobo for your detailed review comments.
>>>
>>> We will address these in the next revision.
>>>
>>> Happy holidays.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> From: "Nobo Akiya (nobo)" <nobo@cisco.com <mailto:nobo@c= isco.com>>
>>> Date: Wednesday, 24 December, 2014 5:45 PM
>>> g
>>> >
>>> >
>>> Subject: Mail regarding
>>>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>>> Resent-To: "frederic.jounay@orange.ch
>>>"=3DSMTP:mtaillon@cisco. com"
>>> Resent-Date: Wednesday, 24 December, 2014 5:46 PM
>>>
>>> Hi Authors,
>>>
>>> Happy Holidays!
>>>
>>> I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 = (as part of
>>>its WG adoption poll), and had some questions/comments. Pl= ease find
>>>them below.
>>>
>>> 1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT su= bobject may
>>> be easier to understand if "list" is used.
>>>
>>> [OLD]
>>>
>>>     The BYPASS_ASSIGNMENT subobject i= s added in the RECORD_ROUTE
>>> object
>>>
>>>     prior to adding the node's IP add= ress in the node-ID subobject.
>>> A
>>>
>>>     node MUST NOT add a BYPASS_ASSIGN= MENT subobject without also
>>> adding a
>>>
>>>     Node-ID subobject.  A node M= UST NOT add a BYPASS_ASSIGNMENT
>>> subobject
>>>
>>>     without also adding an IPv4 or IP= v6 subobject.
>>>
>>> [NEW]
>>>
>>>     When the BYPASS_ASSIGNMENT subobj= ect is added in the
>>> RECORD_ROUTE
>>>
>>>     object:
>>>
>>>     o  The BYPASS_ASSIGNMENT sub= object MUST be added prior to the
>>> node-ID
>>>
>>>        subobject descr= ibing the node's IP address.
>>>
>>>     o  The Node-ID subobject MUS= T also be added.
>>>
>>>     o  The IPv4 or IPv6 subobjec= t MUST also be added.
>>>
>>> 2) Section 4.4.1 - First sentence of the third paragraph = was quite
>>> difficult to read/understand. Perhaps adding some commas = and
>>> quotations may improve its readability.
>>>
>>> [OLD]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject whose bypass tunnel and= the node-ID subobject when
>>> used as
>>>
>>>     a bypass tunnel source terminates= locally assigns the matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> [NEW]
>>>
>>>     The upstream PLR (downstream MP) = that detects a
>>> BYPASS_ASSIGNMENT
>>>
>>>     subobject, whose bypass tunnel an= d the node-ID subobject when
>>> used as
>>>
>>>     a "bypass tunnel source"= ; terminates locally, assigns the
>>> matching
>>>
>>>     bidirectional bypass tunnel in th= e reverse direction, and
>>> forwards
>>>
>>>     the RSVP Path message downstream.=
>>>
>>> 3) Section 4.4.1 - I have a slight concern regarding belo= w statement.
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>>     In the case of upstream PLR recei= ving multiple BYPASS_ASSIGNMENT
>>>
>>>     subobjects from multiple downstre= am PLRs, the decision of
>>> selecting a
>>>
>>>     bypass tunnel in the reverse dire= ction can be based on local
>>> policy,
>>>
>>>     for example, prefer link protecti= on versus node protection
>>> bypass
>>>
>>>     tunnel, or prefer the most upstre= am versus least upstream node
>>>
>>>     protection bypass tunnel.
>>>
>>> [snip]
>>>
>>> When LSRs within a bidirectional LSP employ different pol= icies, as
>>> described above, then we can result in pockets where ther= e are no
>>> protections.
>>>
>>> For example:
>>>
>>> Node A uses node protection.
>>>
>>> Node B and C use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>>         &nbs= p; ^     /
>>>
>>>         &nbs= p;  \   /
>>>
>>>         &nbs= p;   +-+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> Another example:
>>>
>>> Node A and C use node protection.
>>>
>>> Node B use link protection.
>>>
>>>      +---------+
>>>
>>>     /     &n= bsp; +-+ \
>>>
>>>    /       /=    \ \
>>>
>>> /       /   =   v v
>>>
>>> A ----- B ----- C
>>>
>>> ^         &n= bsp;    /
>>>
>>>    \      &n= bsp;     /
>>>
>>>     +----------+
>>>
>>> The result of above is that, in the reverse direction, th= ere will
>>> not be any protection between nodes B and A.
>>>
>>> In both cases, if there is a breakage of the link connect= ing nodes A
>>> and B, then node C receives the RSVP PATH message. If nod= e C follows
>>> procedures described in Section 6.2, then it will not fin= d a
>>> matching bypass tunnel.
>>>
>>> If I'm off track, then I apologize for the noise. If abov= e is indeed
>>> a problem, then this limitation should at least be descri= bed in the
>>> document, followed by a recommendation of all LSRs within= a
>>> bidirectional tunnel employing the same policy.
>>>
>>> It may be possible to (be brave and) address this but it = will
>>> require more procedures. I'll leave the decision and furt= her
>>> investigation to the authors.
>>>
>>> 4) Section 4.4.1 - Should there be SHOULD or MUST in this= paragraph?
>>>
>>> [snip]
>>>
>>>     In the absence of BYPASS_ASSIGNME= NT subobject, the upstream PLR
>>> does
>>>
>>>     not assign a bypass tunnel in the= reverse direction.  This
>>> allows the
>>>
>>>     downstream PLR to always initiate= the bypass assignment and
>>> upstream
>>>
>>>     PLR to simply reflect the bypass = assignment.
>>>
>>> [snip]
>>>
>>> I'm guessing that there should be a SHOULD ...
>>>
>>> 5) Section 6.2 - "If" and "If not" in= below text do not correspond
>>> to each other (thus a bit confusing).
>>>
>>> [snip]
>>>
>>>        - If found, che= cks whether the primary LSP traffic and
>>> signaling
>>>
>>>          are= already rerouted over the found bypass tunnel.  If not,
>>> PRR
>>>
>>>          R5 = activates FRR reroute procedures to direct traffic and
>>>
>>>          RSV= P Resv over the found bypass tunnel T2 in the
>>>
>>>          rev= erse direction.
>>>
>>> [snip]
>>>
>>> If we write above with a psuedocode, then it will be:
>>>
>>>      if (bypass tunnel found) {&= nbsp;     // "If found" is this line
>>>
>>>          che= ck if already rerouted
>>>
>>>          if = (not already rerouted) { // "If not" is this line
>>>
>>>         &nbs= p;     active FRR reroute
>>>
>>>          }
>>>
>>>      }
>>>
>>> It  might make the texts easier to read/understand i= f you can
>>> rephrase it a bit?
>>>
>>> Thanks!
>>>
>>> -Nobo
>>>
>>>
>>>
>>> _______________________________________________
>>> Teas mailing list
>>>
>>
>>--
>>
>>
>>Loa Andersson        &= nbsp;           &nbs= p;   email: loa@mail01.huawei.com
>>Senior MPLS Expert       &n= bsp;            = ;      loa@pi.nu<= /div>
>>Huawei Technologies (consultant)     phone= : +46 739 81 21 64
>>
>>_______________________________________________
>>Teas mailing list
>
 
 
--_000_D0EA968F4D3AArgandhiciscocom_-- From nobody Sun Jan 25 14:33:28 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7F1A006B; Sun, 25 Jan 2015 14:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 nXW2GfFvXJyP; Sun, 25 Jan 2015 14:33:25 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1334D1A0067; Sun, 25 Jan 2015 14:33:24 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0PMXJF8015113; Sun, 25 Jan 2015 22:33:19 GMT Received: from 950129200 (089144192127.atnat0001.highway.a1.net [89.144.192.127]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0PMXH9m015078 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2015 22:33:18 GMT From: "Adrian Farrel" To: "'Lou Berger'" , "'Rakesh Gandhi \(rgandhi\)'" , References: <14b21ac25e8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <14b21ac25e8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Sun, 25 Jan 2015 22:33:16 -0000 Message-ID: <00d601d038ee$eb7ca210$c275e630$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI88WGiogHvZcp1NqBlxBaUY+M30AIalCVcm+ciQtA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21284.003 X-TM-AS-Result: No--19.042-10.0-31-10 X-imss-scan-details: No--19.042-10.0-31-10 X-TMASE-MatchedRID: vEvJ7Rh1lGjRhEyb9f1sjl2036HHwFm/fjJOgArMOCY3Z3efQH+wjz5R eTebdoC/3k+CPiKHMcIsj8fcDwSC8OZxANRnIohBjWe5HOFKvuNAq6/y5AEOOuOxOq7LQlGL2dQ 0jXJJWgn4Dxkm5kWWhzF5qY1TEAb3r5q5CjU40fG7vYqkCS0dL5Vl8bxyvq1e55TSoW/nwH4Xbg /jJpukNvHB7b2zE9JzBKp+mv94eitQVAugxckN0xkas6i0MbpOkT7cMJfe6JvqLnOUXH9QdEK3S A4hIPQq6ENzG6ol6Aivh3ewfsNrXNOD37/ztihFBEfU2vugRF1T4DtiSkMnWMu4R0wGfYgMgqLW Qyr3mKV3CcjY/aFtmrcM7XmcaNnTzsxad8fKloY00dkxYNMRt30tCKdnhB58vqq8s2MNhPB9j2G wzTE3vSq2rl3dzGQ1A/3R8k/14e0= Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 22:33:27 -0000 Hi Lou, Rakesh, all... [snip] > > >5.3 has > > > > > > If REVERSE_LSP Object is not present in the received Path message of > > > the LSP, the egress node SHOULD use the LSP properties from the > > > received LSP Path message to signal the LSP in the reverse direction > > > (which may depend on the local policy). > > > > > >This worries me. Do you mean that in the absence of a REVERSE_LSP object > > >containing an ERO, the reverse LSP MUST be co-routed with the forward > > >LSP? > > > > No. There will also be no (forward LSP) full ERO in the LSP either to > > do that. > > Does following work? > > > > If REVERSE_LSP Object is not present in the received Path message of > > the LSP, the egress node MAY use the LSP properties from the > > received LSP Path message to signal the LSP in the reverse direction > > that MAY or MAY NOT follow the forward LSP path > > (which may depend on the local policy). > > Humm, I think we should dig into this a bit more before making this change. > > Adrian, > > Do you have a specific concern with the existing text that you would like > to see addressed ? > > I think the proposed revision is even less helpful. 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" because it implies you have a choice. 2. The ERO was just an example of what was worrying me. That is, that in the absence of sub-objects in the REVERSE_LSP object, the receiving end point SHOULD (i.e., is strongly directed to unless there is an unusual variation) use the parameters from the forward direction to govern the reverse LSP. It seems to me that there are probably different classes of information that fit into: - MUST be in the REVERSE_LSP object or everything will fail (I believe this is the empty set) - MUST be used from the forward LSP if not in the REVERSE_LSP object - SHOULD be used from the forward LSP if not in the REVERSE_LSP object - MAY be used from the forward LSP if not in the REVERSE_LSP object - MUST NOT be used from the forward LSP if not in the REVERSE_LSP object TSpec is a simple example of SHOULD (although maybe the reverse path TSpec should be modelled on the FlowSpec that will was sent on the Resv?). ERO (derived from the RRO) is either a MAY or a SHOULD depending on your thought pattern (some people think the default should be that the two LSPs fate share). The Session Name in the Session Attribute object seems like a MAY (noting that the name might already be in use). The Alarm_Spec object looks like a MUST NOT. Etc. I'm open to being persuaded that this collapses to one or two bullets. But if it is more than one bullet, I think there is work to be done to list it out. And that also worries me for extensibility - when I define a new object carried in a Path message, who is going to think about and document which class it belongs to? Perhaps "MAY" is the vaguest and safest? Adrian From nobody Mon Jan 26 03:26:29 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009581A8910; Mon, 26 Jan 2015 03:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DrRGdia_0tT3; Mon, 26 Jan 2015 03:21:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9D31A882F; Mon, 26 Jan 2015 03:21:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK89819; Mon, 26 Jan 2015 11:21:21 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 11:21:20 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 19:21:16 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(5): Challenge of Hot-standby for SR-TE Path Thread-Index: AQHQOVoyK64QSjXka0yfZ8lTIcYadw== Date: Mon, 26 Jan 2015 11:21:15 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968B@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Mon, 26 Jan 2015 03:26:27 -0800 Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [Teas] New Comments on Segment Routing(5): Challenge of Hot-standby for SR-TE Path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:21:25 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZmlm dGggY29tbWVudHMgb24gc2VnbWVudCByb3V0aW5nLiBJdCBpcyByZWxhdGVkIHdpdGggU1ItVEUg cGF0aCBhbmQgSSBpbmNsdWRlIHRoZSBURUFTIFdHIGluIHRoZSBkaWN1c3Npb24uDQoNCg0KDQog ICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAgICAgMQ0KICBTMTEt LS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1TMTQtLS0tLS0tLS1TMTUNCiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgMXwg ICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAgICAgICAgMXwgICAgICAgICAgMXwNCiAgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgUzIx LS0tLS0tLS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1DQogICAg ICAgICA0ICAgICAgICAgICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KDQpNUExTIFRF IGhvdHN0YW5keSBpcyBhbHdheXMgYWRvcHRlZCBpbiB0aGUgTVBMUyBmb3IgdGhlIHRyYWZmaWMg cHJvdGVjdGlvbi4gSW4gb3JkZXIgdG8gYXZvaWQgb25lIG5vZGUvbGluayBmYWlsdXJlIGNhdXNl DQoNCmJvdGggdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGJlY29tZXMgZG93 biwgaXQgaXMgcmVxdWlyZWQgdGhhdCB0aGUgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwIHBh dGggc2hvdWxkDQoNCmJlIHRvdGFsbHkgZGlzam9pbnRlZC4NCg0KDQoNCkkgYXNzdW1lIHRoYXQg dGhlIGRlc2lnbiBwcmluaWNpcGxlIHNob3VsZCBiZSBhbHNvIGFwcGxpZWQgdG8gdGhlIFNSLVRF IHBhdGguIElmIHNvLCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBhYm92ZSB0b3BvbG90eQ0KDQog KHRoZSBudW1iZXJzIG5lYXIgdGhlIGxpbmUgcmVwcmVzZW50IHRoZSBtZXRyaWNzIG9mIHRoZSBs aW5rcyksIGluIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGUgZGlzam9pbnQgb2YgdGhlIHByaW1hcnkg cGF0aA0KDQphbmQgdGhlIGJhY2t1cCBwYXRoLCB0aGUgbGFiZWwgc3RhY2sgWyBTMjIgU0woUzIy L1MyMykgUzIzIFNMKFMyMy8yNCkgUzI0IFNMKFMyNC9TMjUpIFMxNSBdIChTTCBtZWFucyB0aGUg bGluayBzZWdtZW50DQoNCmJldHdlZW4gdGhlIHR3byBuZWlnaGJvcmluZyBub2RlcykgbXVzdCBi ZSBzcGVjaWZpZWQgZm9yIHRoZSBob3RzdGFuZGJ5IHBhdGguIFNvIGluIHRoZSBjYXNlIHRoZXJl IG1heWJlIG1vcmUgbGFiZWxzIHRvIGJlDQoNCmVuY2Fwc3VsYXRlZCBmb3IgdGhlIHBhY2tldHMg Zm9yd2FyZGVkIHRocm91Z2ggdGhlIGhvdC1zdGFuZGJ5IHBhdGguIEl0IG1heSBiZSBlYXN5IHRv IGV4Y2VlZCB0aGUgaGFyZHdhcmUgbGltaXRhdGlvbiBhbmQNCg0KY2F1c2UgdGhlIGxvdyBlZmZp Y2llbmN5IHBheWxvYWQuDQoNCkkgd29uZGVyIGlmIHlvdSB0aGluayBhYm91dCB0aGUgY2hhbGxl bmdlLiBIb3BlIHRvIGdldCB5b3VyIG9waW5pb24gb24gaXQuDQoNCg0KDQoNCg0KUmVnYXJkcywN ClJvYmluDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the fifth comments on segment routing. It= is related with SR-TE path and I include the TEAS WG in the dicussion.

 


         1    &= nbsp;         1   &n= bsp;       1     &nb= sp;      1
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  1|           = 1|           1| &nb= sp;        1|    &nb= sp;     1|
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25
         4    &= nbsp;         4   &n= bsp;       4     &nb= sp;      4

MPLS TE hotstandy is always adopted in the MPLS for the traffic protecti= on. In order to avoid one node/link failure cause

both the primary path and the backup path becomes down, it is requi= red that the primary path and the backup path should

be totally disjointed.

 

I assume that the design priniciple should be also applied to the SR-TE = path. If so, taking into account the above topoloty

 (the numbers near the line represent the metrics of the links), in= order to guarantee the disjoint of the primary path

and the backup path, the label stack [ S22 SL(S22/S23) S23 SL(S23/24) S2= 4 SL(S24/S25) S15 ] (SL means the link segment

between the two neighboring nodes) must be specified for the hotstandby = path. So in the case there maybe more labels to be

encapsulated for the packets forwarded through the hot-standby path= . It may be easy to exceed the hardware limitation and

cause the low efficiency payload.

I wonder if you think about the challenge. Hope to get your opinion on i= t.

 

 


Regards,
Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772968Bnkgeml506mbxchi_-- From nobody Mon Jan 26 03:41:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8681A892C; Mon, 26 Jan 2015 03:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 D4Pr_D03-m0M; Mon, 26 Jan 2015 03:41:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D661A882F; Mon, 26 Jan 2015 03:41:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT07897; Mon, 26 Jan 2015 11:41:07 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 11:41:06 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 19:40:58 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(6): Challenge of Loose Explicit Path for SR-TE Path Thread-Index: AQHQOVry9L8WAh2w3ECX3Jff5mfs3Q== Date: Mon, 26 Jan 2015 11:40:57 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BD@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [Teas] New Comments on Segment Routing(6): Challenge of Loose Explicit Path for SR-TE Path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:41:11 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgc2l4 dGggY29tbWVudHMgb24gc2VnbWVudCByb3V0aW5nLiBJdCBpcyBhbm90aGVyIGlzc3VlIHJlbGF0 ZWQgd2l0aCBTUi1URSBwYXRoLg0KDQogICAgICAgICAgICAgICAgIFM0LS0tUzUNCiAgICAgICAg ICAgICAgICAvICAgICAgIFwNCiAgICBTMS0tLVMyLS0tUzMgICAgICAgICBTOC0tLVM5LS0tUzEw DQogICAgICAgICAgICAgICAgXCAgICAgICAvDQogICAgICAgICAgICAgICAgIFM2LS0tUzcNCg0K Rm9yIE1QTFMgVEUsIHRoZXJlIGFyZSB0d28gdHlwZXMgb2YgZXhwbGljaXQgcGF0aHM6IHN0cmlj dCBhbmQgbG9vc2UuIEV2ZW4gZm9yIHRoZSBsb29zZSBob3AsIHRoZSBpbmdyZXNzIG5vZGUgd2ls bA0KDQpjYWxjdWxhdGUgYWxsIHRoZSBob3BzIHRvIHRoZSBsb29zZSBob3AuIEFuZCB0aGUgTVBM UyBURSBwYXRoIGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHJvdXRpbmcsIHRoaXMgbWVhbnMgZXZl biBpZg0KDQp0aGUgcm91dGUgY2hhbmdlLCB0aGUgTVBMUyBURSBwYXRoIHRvIHRoZSBsb29zZSBo b3AgY2FuIGJlIGtlcHQuIEZvciBleGFtcGxlLCBhcyBzaG93biBpbiB0aGUgYWJvdmUgZmlndXJl LCBpZiB0aGUNCg0KaW5ncmVzcyBTMSBjb25maWd1cmVzIHRoZSBsb29zZSBob3AgUzggdG8gdGhl IGRlc3RpbmF0aW9uIFMxMCwgaXQgd2lsbCBjYWxjdWxhdGUgdGhlIHBhdGggUzEtPlMyLT5TMy0+ UzQtPlM1LT5TOC0+UzktPlMxMC4NCg0KSWYgdGhlIG1ldHJpYyBjaGFuZ2VzIGZvciB0aGUgbGlu ayBiZXR3ZWVuIFMzIGFuZCBTNCBhbmQgbWFrZSB0aGUgc2hvcnRlc3Qgcm91dGUgcGF0aCB0byBT OCBmcm9tIHRoZSBTMy0+UzQtPlM1LT5TOCB0bw0KUzMtPlM2LT5TNy0+UzguIEJ1dCB0aGUgZXhp dGluZyBNUExTIFRFIHBhdGggd2lsbCBub3QgY2hhbmdlIGFjY29yZGluZ2x5Lg0KDQoNCg0KRm9y IFNSLUJFIFBhdGgsIGlmIHRoZSBsb29zZSBob3AgaXMgY29uZmlndXJlZCwgdGhlcmUgd2lsbCBi ZSB0d28gcG9zc2libGUgY2hvaWNlczoNCk9wdGlvbiAxLiBTYW1lIGFzIHRoZSBleGlzdGluZyBN UExTIFRFLg0KDQpJZiB0aGUgb3B0aW9uIGlzIGFkb3B0ZWQsIHRoZXJlIHdpbGwgYmUgZm9sbG93 aW5nIGNoYWxsZW5nZXM6DQoxKSBUaGlzIG1lYW5zIHRoZSBsb29zZSBob3AgY2Fubm90IHJlZHVj ZSB0aGUgbGFiZWwgc3RhY2sgZm9yIHRoZSBTUi1URSBwYXRoLiBJdCBuZWVkIG1vcmUgbGFiZWxz IHRvIGJlIGVuY2Fwc3VsYXRlZCBhZnRlcg0KDQpjYWxjdWxhdGluZyB0aGUgd2hvbGUgcGF0aCBh bmQgcmVwcmVzZW50aW5nIGVhY2ggaG9wIHdpdGggbm9kZSBsYWJlbCBvciBhZGphY2VuY3kgbGFi ZWwuIFRoZSBkZWVwIGRlcHRoIG9mIHRoZSBsYWJlbCBzdGF0Y2sNCg0KIG1heSBleGNlZWRzIHRo ZSBoYXJkd2FyZSBsaW1pdGF0aW9uIG9yIGNhdXNlIGxvdyBlZmZpY2llbmN5IHBheWxvYWQuDQoy KSBNb3JlIGNoYWxsZW5nZXMgY2FuIGJlIHByb3Bvc2VkIGZyb20gdGhlIGludGVyLWFyZWEgYmFo YXZpb3IuIElmIFBDRSBpcyBub3QgYWRvcHRlZCwgaWYgdGhlIGluZ3Jlc3Mgbm9kZSBoYXMgdG8g b25seQ0KDQpzcGVjaWZ5IHRoZSBBQlJzIGFzIHRoZSBsb29zZSBob3AgdG8gdGhlIGRlc3RpbmF0 aW9uIGZvciBpbnRlci1hcmVhLCBmb3IgTVBMUyBURSwgdGhlIGluZ3Jlc3Mgbm9kZSBjYW4gYWNx dWlyZSB0aGUgZW5kLXRvLWVuZA0KDQpwYXRoIGluZm8gdGhyb3VnaCBSUk8uICBCdXQgc2luY2Ug dGhlcmUgaXMgbm8gUlJPLWxpa2UgbWVjaGFuaXNtIGluIElHUCwgaXQgaXMgaW1wb3NzaWJsZSBm b3IgU1ItVEUgcGF0aCB0byBnZXQgdGhlIGVuZC10by1lbmQNCg0KcGF0aCBpbmZvLiBUaGlzIG1l YW5zIHRoZSBpbmdyZXNzIG5vZGUgY2Fubm90IGdldCB0aGUgd2hvbGUgbGFiZWwgc3RhY2sgaW5m byB0byBkZXRlcm1pbmUgdGhlIHdob2xlIFNSLVRFIHBhdGguDQoNCg0KDQpPcHRpb24gMi4gTGlt aXRlZCBsYWJlbHMgZm9yIHRoZSBsb29zZSBob3AuIEZvciBleGFtcGxlLCBzaW5jZSBvbmx5IGxv b3NlIGhvcCBTOCBpcyBzcGVjaWZpZWQsIHRoZW4gdGhlIGxhYmVsIHN0YWNrIGZvciB0aGUNCg0K U1ItVEUgcGF0aCB0byB0aGUgUzEwIGlzIFtTOCBTMTBdLiBUaGF0IGlzLCB0d28gbGF5ZXJzIG9m IGxhYmVscyBpcyBlbm91Z2guDQoNClRoaXMgbWV0aG9kIGNhbiBhdm9pZCB0aGUgZGVlcCBsYWJl bCBzdGFjayBpc3N1ZS4gQnV0IGl0IHdpbGwgaW50cm9kdWNlIG90aGVyIGlzc3Vlcy4gSW4gZmFj dCwgZm9yIHRoZSBTUi1URSBwYXRoLCBpdCBtaXhlcw0KDQp0aGUgcm91dGUgcGF0aCBhbmQgdGhl IFRFIHBhdGggdG9nZXRoZXIuIFRoZXJlIG1heSBiZSBmb2xsb3dpbmcgaXNzdWVzOg0KDQoxKSBU aGUgcm91dGUgY2hhbmdlIHdpbGwgaGF2ZSBlZmZlY3Qgb24gdGhlIFNSLVRFIHBhdGguIElmIHRo ZSByb3V0ZXMgdG8gdGhlIFM4IGlzIGNoYW5nZXMsIHRoZSBTUi1URSBwYXRoIHRvIHRoZSBTMTAg d2lsbA0KDQpjaGFuZ2UgYWNjb3JkaW5nbHkuDQoyKSBGb3IgdGhlIGluZ3Jlc3Mgbm9kZSwgZnJv bSB0aGUgcG9pbnQgb2YgdGhlIG5ldHdvcmsgbWFpbnRlbmFuY2UgdmlldywgaXQgbG9zZXMgdGhl IGNvbnRyb2wgb24gdGhlIGVuZC10by1lbmQgcGF0aC4gVGhhdCBpcywNCg0KdGhlIGVuZC10by1l bmQgcGF0aCBpcyB1bmtub3duIHRvIHRoZSBpbmdyZXNzIG5vZGUuDQozKSBJZiB0aGVyZSBpcyBs b2FkIGJhbGFuY2UgZm9yIHRoZSByb3V0ZSwgZm9yIGV4YW1wbGUsIHRoZXJlIGFyZSB0d28gZXF1 YWwgcGF0aHMgdG8gUzggYXMgdGhlIGFib3ZlIHRvcG9sb2d5OiBTMy0+UzQtPlM1LT5TOCwNCg0K UzMtPlM2LT5TNy0+UzguSWYgQkZEIGlzIGVuYWJsZWQgZm9yIHRoZSBTUi1URSBwYXRoLCB0aGUg QkZEIHBhY2tldHMgYW5kIHRoZSByZWFsIHRyYWZmaWMgbWF5IGdvIHRocm91Z2ggZGlmZmVyZW50 IHBhdGguDQoNClRoZXJlIHdpbGwgYmUgdGhlIHBvc3NpYmlsaXR5IHRoYXQgQkZEIHdpbGwgZGV0 ZWN0IHRoZSB3cm9uZyBwYXRoIGFuZCBtYXkgY2F1c2UgZnVydGhlIHByb2JsZW0gc3VjaCBhcyB0 aGUgd3JvbmcgdHJhZmZpYyBzd2l0Y2guDQoNCg0KDQpJIHdvbmRlciBpZiB0aGUgaXNzdWUgaGFz IGJlZW4gdGFrZW4gaW50byBhY2NvdW50IGFuZCB3aGljaCBvcHRpb24geW91IHByZWZlci4NCg0K DQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the sixth comments on segment routing. It= is another issue related with SR-TE path.


            &nb= sp;    S4---S5
            &nb= sp;   /       \
    S1---S2---S3       &n= bsp; S8---S9---S10
            &nb= sp;   \       /
            &nb= sp;    S6---S7


For MPLS TE, there are two types of explicit paths: strict and loose. Even = for the loose hop, the ingress node will

calculate all the hops to the loose hop. And the MPLS TE path is indepen= dent from the routing, this means even if

the route change, the MPLS TE path to the loose hop can be kept. For exa= mple, as shown in the above figure, if the

ingress S1 configures the loose hop S8 to the destination S10, it will c= alculate the path S1->S2->S3->S4->S5->S8->S9->S10.

If the metric changes for the link between S3 and S4 and make the shorte= st route path to S8 from the S3->S4->S5->S8 to
S3->S6->S7->S8. But the exiting MPLS TE path will not change accor= dingly.

 

For SR-BE Path, if the loose hop is configured, there will be two possib= le choices:
Option 1. Same as the existing MPLS TE.

If the option is adopted, there will be following challenges:
1) This means the loose hop cannot reduce the label stack for the SR-TE pat= h. It need more labels to be encapsulated after

calculating the whole path and representing each hop with node label or = adjacency label. The deep depth of the label statck

 may exceeds the hardware limitation or cause low efficiency payloa= d.
2) More challenges can be proposed from the inter-area bahavior. If PCE is = not adopted, if the ingress node has to only

specify the ABRs as the loose hop to the destination for inter-area, for= MPLS TE, the ingress node can acquire the end-to-end

path info through RRO.  But since there is no RRO-like me= chanism in IGP, it is impossible for SR-TE path to get the end-to-end

path info. This means the ingress node cannot get the whole label stack = info to determine the whole SR-TE path.

 

Option 2. Limited labels for the loose hop. For example, since only loos= e hop S8 is specified, then the label stack for the

SR-TE path to the S10 is [S8 S10]. That is, two layers of labels is enou= gh.

This method can avoid the deep label stack issue. But it will introduce = other issues. In fact, for the SR-TE path, it mixes

the route path and the TE path together. There may be following issues:<= /p>

1) The route change will have effect on the SR-TE path. If the routes to= the S8 is changes, the SR-TE path to the S10 will

change accordingly.
2) For the ingress node, from the point of the network maintenance view, it= loses the control on the end-to-end path. That is,

the end-to-end path is unknown to the ingress node.
3) If there is load balance for the route, for example, there are two equal= paths to S8 as the above topology: S3->S4->S5->S8,

S3->S6->S7->S8.If BFD is enabled for the SR-TE path, the BFD pa= ckets and the real traffic may go through different path.

There will be the possibility that BFD will detect the wrong path and ma= y cause furthe problem such as the wrong traffic switch.

 

I wonder if the issue has been taken into account and which option you p= refer.

 

 

 

 

Regards,

Robin

 

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D477296BDnkgeml506mbxchi_-- From nobody Mon Jan 26 05:34:01 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2D1A8AA5; Mon, 26 Jan 2015 05:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xqEaRayVxrnz; Mon, 26 Jan 2015 05:33:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE691A8A9E; Mon, 26 Jan 2015 05:33:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126133353.6741.72631.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 05:33:53 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:33:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs Authors : Mike Taillon Tarek Saad Rakesh Gandhi Zafar Ali Manav Bhatia Lizhong Jin Filename : draft-ietf-teas-gmpls-lsp-fastreroute-02.txt Pages : 16 Date : 2015-01-26 Abstract: This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR to avoid RSVP soft-state timeout. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-fastreroute-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 26 05:37:51 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0508D1A8AAB for ; Mon, 26 Jan 2015 05:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ptEwoA4zhMCr for ; Mon, 26 Jan 2015 05:37:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97F81A8A08 for ; Mon, 26 Jan 2015 05:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2540; q=dns/txt; s=iport; t=1422279465; x=1423489065; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g29IyR4y2961olkQ7rgNR4w0jFqGvZZmE2f1on1iya8=; b=jAYgxAiehk3hQe0LSxKmjP5KOFOw5cG5lBc9tIxnpSIJJ0NXZ9ZpKYve riuFJKHoa0TV0MhmlW1qHGuMnKSBGQgC2kex6INhasTojdok8NaCRkz3K A1pE0LBF9Xr+oWIzYYVzxjBHbvhdMhoq3B7wjlG07goX1X5oF9UV9iuU5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFAM9CxlStJA2F/2dsb2JhbABagwZSVAUExjIMhW8CgRhDAQEBAQF9hA0BAQQBAQE3NAsSAQgSJDcLFw4CBA4FCYgjCAXTGQEBAQEBAQEDAQEBAQEBAQEBGY9FMweEKQWNDYFhg0uFVoEVNoJJimuDPSKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,469,1418083200"; d="scan'208";a="390802814" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jan 2015 13:37:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0QDbia2021846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jan 2015 13:37:45 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 07:37:44 -0600 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-02.txt Thread-Index: AQHQOWzLhEOUUu/XPEy03oAxWe2jcZzSeGqA Date: Mon, 26 Jan 2015 13:37:44 +0000 Message-ID: In-Reply-To: <20150126133353.6741.72631.idtracker@ietfa.amsl.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.237.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <5102A96054DCC74A96FBF49034B9ED01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Gregory Mirsky Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-lsp-fastreroute-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:37:48 -0000 Hi WG, We have uploaded a new revision with following changes: - added text for revertive behaviour as per request from Greg. - minor editorial changes. Welcome your review comments. thanks, Rakesh On 2015-01-26 8:33 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Traffic Engineering Architecture and >Signaling Working Group of the IETF. > > Title : Extensions to Resource Reservation Protocol For >Fast Reroute of Traffic Engineering GMPLS LSPs > Authors : Mike Taillon > Tarek Saad > Rakesh Gandhi > Zafar Ali > Manav Bhatia > Lizhong Jin > Filename : draft-ietf-teas-gmpls-lsp-fastreroute-02.txt > Pages : 16 > Date : 2015-01-26 > >Abstract: > This document defines Resource Reservation Protocol - Traffic > Engineering (RSVP-TE) signaling extensions to support Fast Reroute > (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol > Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling > extensions allow the coordination of bidirectional bypass tunnel > assignment protecting a common facility in both forward and reverse > directions of a co-routed bidirectional LSP. In addition, these > extensions enable the re-direction of bidirectional traffic and > signaling onto bypass tunnels that ensure co-routedness of data and > signaling paths in the forward and reverse directions after FRR to > avoid RSVP soft-state timeout. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-gmpls-lsp-fastreroute-0= 2 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Mon Jan 26 05:54:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AEB1A8A9A; Mon, 26 Jan 2015 05:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QLycwovERe8u; Mon, 26 Jan 2015 05:54:39 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101DE1A8774; Mon, 26 Jan 2015 05:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3787; q=dns/txt; s=iport; t=1422280479; x=1423490079; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Au6kj+FAscdAuCJCLGar3gsa26CXnmL8Pnv6UBEupsc=; b=LBB4fJil+bInLo0mc2+ndyO1Wlgsxd9xNurL8KVdPd8SC3zYJQ7FYD4r sf8Y/2gxEU8vp28W7pAm0u4fzzKQyx0VUj+XTWu/KlAIsJ8Uoj803wY7U WHpM6KcOww8hw9+K/L2GT+S/xfUz07ddaE6HjEMNq57iHxPQ0sX9V3KuW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B0BQDfRcZU/40NJK1UBoMGgSsEzC0CgRhDAQEBAQF9hA0CBDotEhIBCDZCJQEBBAENBYgs0zABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjzUYKwcChCcFjQ2BYYkhgRWNaoM9IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,469,1418083200"; d="scan'208";a="117570863" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 26 Jan 2015 13:54:38 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0QDsbsb027098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Jan 2015 13:54:37 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 07:54:37 -0600 From: "Rakesh Gandhi (rgandhi)" To: "adrian@olddog.co.uk" , "'Lou Berger'" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" Thread-Topic: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiABoSkuAADAF+qYAG8A1AAAVsrWA Date: Mon, 26 Jan 2015 13:54:36 +0000 Message-ID: In-Reply-To: <00d601d038ee$eb7ca210$c275e630$@olddog.co.uk> 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.237.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <668E532689DBCD49B5A3021B08DBCADF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:54:41 -0000 Hi Adrian, Thanks for your inputs. If the initiator really needs a specific behaviour, and depending on it, it should signal the egress node via REVERSE_LSP. IMO, MAY gives a reasonable choice for the egress node to do the right thing and if that is not what the initiator prefers, it can alter it by signaling REVERSE_LSP. " If REVERSE_LSP Object is not present in the received Path message of the LSP, the egress node MAY use the LSP properties from the received LSP Path message to signal the LSP in the reverse direction (which may depend on the local policy). " Thanks, Rakesh On 2015-01-25 5:33 PM, "Adrian Farrel" wrote: >Hi Lou, Rakesh, all... > >[snip] > >> > >5.3 has >> > > >> > > If REVERSE_LSP Object is not present in the received Path message >>of >> > > the LSP, the egress node SHOULD use the LSP properties from the >> > > received LSP Path message to signal the LSP in the reverse >>direction >> > > (which may depend on the local policy). >> > > >> > >This worries me. Do you mean that in the absence of a REVERSE_LSP >>object >> > >containing an ERO, the reverse LSP MUST be co-routed with the forward >> > >LSP? >> > >> > No. There will also be no (forward LSP) full ERO in the LSP >>either to >> > do that. >> > Does following work? >> > >> > If REVERSE_LSP Object is not present in the received Path message >>of >> > the LSP, the egress node MAY use the LSP properties from the >> > received LSP Path message to signal the LSP in the reverse >>direction >> > that MAY or MAY NOT follow the forward LSP path >> > (which may depend on the local policy). >>=20 >> Humm, I think we should dig into this a bit more before making this >>change. >>=20 >> Adrian, >>=20 >> Do you have a specific concern with the existing text that you would >>like >> to see addressed ? >>=20 >> I think the proposed revision is even less helpful. > >1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" >because it >implies you have a choice. > >2. The ERO was just an example of what was worrying me. That is, that in >the >absence of sub-objects in the REVERSE_LSP object, the receiving end point >SHOULD (i.e., is strongly directed to unless there is an unusual >variation) use >the parameters from the forward direction to govern the reverse LSP. It >seems to >me that there are probably different classes of information that fit into: >- MUST be in the REVERSE_LSP object or everything will fail (I believe >this is >the empty set) >- MUST be used from the forward LSP if not in the REVERSE_LSP object >- SHOULD be used from the forward LSP if not in the REVERSE_LSP object >- MAY be used from the forward LSP if not in the REVERSE_LSP object >- MUST NOT be used from the forward LSP if not in the REVERSE_LSP object > >TSpec is a simple example of SHOULD (although maybe the reverse path TSpec >should be modelled on the FlowSpec that will was sent on the Resv?). >ERO (derived from the RRO) is either a MAY or a SHOULD depending on your >thought >pattern (some people think the default should be that the two LSPs fate >share). >The Session Name in the Session Attribute object seems like a MAY (noting >that >the name might already be in use). >The Alarm_Spec object looks like a MUST NOT. >Etc. > >I'm open to being persuaded that this collapses to one or two bullets. >But if it >is more than one bullet, I think there is work to be done to list it out. >And >that also worries me for extensibility - when I define a new object >carried in a >Path message, who is going to think about and document which class it >belongs >to? >Perhaps "MAY" is the vaguest and safest? > >Adrian > From nobody Mon Jan 26 07:06:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2E1A9025 for ; Mon, 26 Jan 2015 07:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 TfQbQav9DWAv for ; Mon, 26 Jan 2015 07:06:32 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 055501A8918 for ; Mon, 26 Jan 2015 07:06:31 -0800 (PST) Received: (qmail 17892 invoked by uid 0); 26 Jan 2015 15:06:30 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 26 Jan 2015 15:06:30 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id kf5V1p0092SSUrH01f5Yxj; Mon, 26 Jan 2015 08:05:32 -0700 X-Authority-Analysis: v=2.1 cv=NPZGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=LbP4ETkKep9zakKEg3MA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bMSrljrl9SiEzxao/rTmUCJY/fvimnngmpR4p5t1yXo=; b=AFO+G6IniqOfagMrGpzsSi+LUmzDsv+uPU4ftMx3fRWgqNzLgO555YsHMudJ6Bu9hLw5UiXUbWDUD/bmH5MUeXiwWoIAun8/ieWzBr8z4txPzI7mSo46is0703K+KGGZ; Received: from box313.bluehost.com ([69.89.31.113]:57481 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YFlEH-0002Tc-1S; Mon, 26 Jan 2015 08:05:29 -0700 Message-ID: <54C657B5.4000104@labn.net> Date: Mon, 26 Jan 2015 10:05:25 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" , "adrian@olddog.co.uk" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:06:34 -0000 On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian, > > Thanks for your inputs. > > If the initiator really needs a specific behaviour, and depending on it, > it should signal the egress node via REVERSE_LSP. This is a key point. From an interoperability standpoint there needs to be expected behavior. > IMO, MAY gives a reasonable choice for the egress node to do the right > thing and if that is not what the initiator prefers, it can alter it by > signaling REVERSE_LSP. > To me "MAY" translates to the initiator not being able to rely on any particular egress' behavior, so from a practical interoperability standpoint this translates to me to be "don't expect anything to work reliably without inclusion of the REVERSE_LSP object". So I really think the proposed language is a bad idea. It seems to me that the options are: (a) require the REVERSE_LSP Object and have it include all objects to be used -- I think this is over kill and optimizes for the special case (b) define predictable behavior when REVERSE_LSP Object isn't present and when the REVERSE_LSP object doesn't contain all objects to be used. -- I agree with Adrian's comment that an object enumeration based approach is risky as it's unclear what happens with new objects. I think this leads to a generic rule / directive which is how I read as the intent of the text that lead to this question. Perhaps we can try to tighten up the language so an egress knows what it SHOULD/MUST do while an ingress can predict behavior? Lou > " > If REVERSE_LSP Object is not present in the received Path message of > the LSP, the egress node MAY use the LSP properties from the > received LSP Path message to signal the LSP in the reverse direction > (which may depend on the local policy). > " > > Thanks, > Rakesh > > > > > On 2015-01-25 5:33 PM, "Adrian Farrel" wrote: > >> Hi Lou, Rakesh, all... >> >> [snip] >> >>>>> 5.3 has >>>>> >>>>> If REVERSE_LSP Object is not present in the received Path message >>> of >>>>> the LSP, the egress node SHOULD use the LSP properties from the >>>>> received LSP Path message to signal the LSP in the reverse >>> direction >>>>> (which may depend on the local policy). >>>>> >>>>> This worries me. Do you mean that in the absence of a REVERSE_LSP >>> object >>>>> containing an ERO, the reverse LSP MUST be co-routed with the forward >>>>> LSP? >>>> >>>> No. There will also be no (forward LSP) full ERO in the LSP >>> either to >>>> do that. >>>> Does following work? >>>> >>>> If REVERSE_LSP Object is not present in the received Path message >>> of >>>> the LSP, the egress node MAY use the LSP properties from the >>>> received LSP Path message to signal the LSP in the reverse >>> direction >>>> that MAY or MAY NOT follow the forward LSP path >>>> (which may depend on the local policy). >>> >>> Humm, I think we should dig into this a bit more before making this >>> change. >>> >>> Adrian, >>> >>> Do you have a specific concern with the existing text that you would >>> like >>> to see addressed ? >>> >>> I think the proposed revision is even less helpful. >> >> 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" >> because it >> implies you have a choice. >> >> 2. The ERO was just an example of what was worrying me. That is, that in >> the >> absence of sub-objects in the REVERSE_LSP object, the receiving end point >> SHOULD (i.e., is strongly directed to unless there is an unusual >> variation) use >> the parameters from the forward direction to govern the reverse LSP. It >> seems to >> me that there are probably different classes of information that fit into: >> - MUST be in the REVERSE_LSP object or everything will fail (I believe >> this is >> the empty set) >> - MUST be used from the forward LSP if not in the REVERSE_LSP object >> - SHOULD be used from the forward LSP if not in the REVERSE_LSP object >> - MAY be used from the forward LSP if not in the REVERSE_LSP object >> - MUST NOT be used from the forward LSP if not in the REVERSE_LSP object >> >> TSpec is a simple example of SHOULD (although maybe the reverse path TSpec >> should be modelled on the FlowSpec that will was sent on the Resv?). >> ERO (derived from the RRO) is either a MAY or a SHOULD depending on your >> thought >> pattern (some people think the default should be that the two LSPs fate >> share). >> The Session Name in the Session Attribute object seems like a MAY (noting >> that >> the name might already be in use). >> The Alarm_Spec object looks like a MUST NOT. >> Etc. >> >> I'm open to being persuaded that this collapses to one or two bullets. >> But if it >> is more than one bullet, I think there is work to be done to list it out. >> And >> that also worries me for extensibility - when I define a new object >> carried in a >> Path message, who is going to think about and document which class it >> belongs >> to? >> Perhaps "MAY" is the vaguest and safest? >> >> Adrian >> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Tue Jan 27 03:24:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9948E1A8782; Tue, 27 Jan 2015 03:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Z7dfOw9pHtQS; Tue, 27 Jan 2015 03:24:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B951A8794; Tue, 27 Jan 2015 03:24:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL96717; Tue, 27 Jan 2015 11:24:32 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 11:24:31 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 19:24:23 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbA== Date: Tue, 27 Jan 2015 11:24:23 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [Teas] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:24:36 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQpUaGlzIGlzIHRoZSBzZXZlbnRo IGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVyZSBhcmUgZm9yIGJvdGggU1ItVEUgcGF0 aCBhbmQgU1ItQkUgcGF0aC4NCg0KDQoNCiAgICAgICAgIDEgICAgICAgICAgICAgIDEgICAgICAg ICAgIDEgICAgICAgICAgICAxDQogIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0t LS0tLVMxNC0tLS0tLS0tLVMxNQ0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KICAxfCAgICAgICAgICAgIDF8ICAgICAgICAgICAxfCAgICAg ICAgICAxfCAgICAgICAgICAxfA0KICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KICBTMjEtLS0tLS0tLS0tLVMyMi0tLS0tLS0tLS1TMjMtLS0t LS0tLS1TMjQtLS0tLS0tLS1TMjUNCiAgICAgICAgIDQgICAgICAgICAgICAgIDQgICAgICAgICAg IDQgICAgICAgICAgICA0DQoNCg0KDQpTdGlsbCB0YWtlIHRoZSB0b3BvbG9neSBpbiB0aGUgY29t bWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlIGxvb3NlIGV4cGxpY2l0IHBhdGgg b3INCg0KdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUg dGhlIE1UVSBvZiB0aGUgaW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KDQpzaW5jZSB0aGUgZGVwdGgg b2YgdGhlIGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBw YXRoIGFyZSBkaWZmZXJlbnQuDQoNClRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZl IHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlIHByaW1hcnkgcGF0aCwgYnV0IG1heSBi ZQ0KDQpmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSBsYWJlbCBzdGFja3Mgb2YgdGhlDQoNCnByaW1hcnkgcGF0aCBh bmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KDQoN Cg0KRnJvbSB0aGUgY2FzZSwgd2UgY2FuIGRlZHVjZSB0aGF0IHRoZSByaXNrIG1heSBleGlzdHMg Zm9yIGFueSBzY2VuYXJpb3MgaW4gd2hpY2ggdGhlIHNhbWUgdHJhZmZpYw0KDQogbWF5IHN3aXRj aCBmcm9tIG9uZSBTUiBwYXRoIHRvIHRoZSBvdGhlciBTUiBwYXRoLiBUaGUgU1IgcGF0aCBpbmNs dWRlcyBTUi1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURQ0KDQpob3RzdGFuZGJ5L3Jlb3B0aW1pemF0 aW9uIGFuZCBTUi1CRSBwYXRoIHN1Y2ggYXMgVEktRlJSLg0KDQoNCg0KQmVzaWRlcyBhYm92ZSBp c3N1ZXMsIExEUC9SU1ZQLVRFIGNhbiBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFjayB0aGUg TVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZQ0KDQpMU1AgdGhyb3VnaCBzaWduYWxsaW5nLiBUaGVu IHRoZSByZWFzb25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRlZCBpbiB0aGUgaW5ncmVzcyBu b2RlLiBGb3IgYm90aA0KDQogU1ItVEUgcGF0aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQgU1It QkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8gc2lnbmFsbGluZyB0byBhZHZlcnRpc2UNCg0KdGhl IGluZm9ybWF0aW9uLiBIb3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJlPyBPciB0aGVyZSBtYXli ZSB0aGUgcmlzayB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQoNCmRyb3BwZWQgYnkgdGhlIG5vZGVz IGFsb25nIHRoZSBMU1AuDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,


This is the seventh commens. The issues proposed here are for both SR-TE pa= th and SR-BE path.

 


         1    &= nbsp;         1   &n= bsp;       1     &nb= sp;      1
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  1|           = 1|           1| &nb= sp;        1|    &nb= sp;     1|
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25
         4    &= nbsp;         4   &n= bsp;       4     &nb= sp;      4

 

Still take the topology in the comment 6 as the example. No matter the l= oose explicit path or

the strict explicit path for the loose hop, assume the MTU of the interf= ace is the same,

since the depth of the label stacks for the primary path and the backup = path are different.

There is the risk that the effetive payload may transmit through the pri= mary path, but may be

fragmented or dropped in the backup path. As the difference between the = label stacks of the

primary path and the backup path increase, the risk will increase.

 

From the case, we can deduce that the risk may exists for any scenarios = in which the same traffic

 may switch from one SR path to the other SR path. The SR path incl= udes SR-TE path such as MPLS TE

hotstandby/reoptimization and SR-BE path such as TI-FRR.

 

Besides above issues, LDP/RSVP-TE can support the path MTU to track the = MTU informaiton along the

LSP through signalling. Then the reasonable MTU info will be adopted in = the ingress node. For both

 SR-TE path (if PCE is not used) and SR-BE path, since there is no = signalling to advertise

the information. How to implement the feature? Or there maybe the risk t= hat the packet may be

dropped by the nodes along the LSP.

 

 

 

Regards,

Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9nkgeml506mbxchi_-- From nobody Tue Jan 27 03:26:58 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669C21A87A5; Tue, 27 Jan 2015 03:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 psnbMuWEsHY8; Tue, 27 Jan 2015 03:26:54 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F251A8794; Tue, 27 Jan 2015 03:26:54 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0RBQmoB012855; Tue, 27 Jan 2015 11:26:49 GMT Received: from 950129200 (62-46-246-49.adsl.highway.telekom.at [62.46.246.49]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0RBQkI7012830 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2015 11:26:47 GMT From: "Adrian Farrel" To: "'Lou Berger'" , "'Rakesh Gandhi \(rgandhi\)'" , References: <54C657B5.4000104@labn.net> In-Reply-To: <54C657B5.4000104@labn.net> Date: Tue, 27 Jan 2015 11:26:47 -0000 Message-ID: <040801d03a24$23b6f190$6b24d4b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFXEwGOXqDNta0qIu90SHkqOz4JqwKxhSN0nbCT7fA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21286.006 X-TM-AS-Result: No--25.871-10.0-31-10 X-imss-scan-details: No--25.871-10.0-31-10 X-TMASE-MatchedRID: gTucSmrmRMOajZkb8TuLc9xajlW+zwxC4NWkOcSKu5SCsBeCv8CM/a0R omhWPJaQqnm20vLe3eCMTIcXG77ZtCC92D94UBz+YD9XTRdaMO1tofdVs4T9OZyka59saICocdy NaJpeZz4Jurkim2B4gzXubl3BW/uubRB32XjjXKuNZ7kc4Uq+46KaxHqGRwkCN2d3n0B/sI/j6f SiVX5Av8bO1XKLQnJ78U8MeFCSDHIwDxuznVf3+a8+ihL49RByYLTkznvC2b+1eX0jEQ9c6i9zy zJUEnZk8cLsihVqoVO3vYzyVgPmf9wrRLDk2cbi/IBH0OAL+EdG/JUd7BvSQp3BT+pdjEe81hAC ileXqfGn8F+M/QMZaxUZqx3zdGw7UjrS/GZo2Epv/kcFnp29GEH7wsB5444wyPQR7DhM3jYsX2N vG8rX7VtAEm108NYIg8D38zQe80juHXE92Wk6HAPZZctd3P4BrMADfyEKZau8MS7k7u0Uf8+cwC LpvDnE4HKqbYlftAOENv7uVcp4NNwMPYvQ+zxsgjO1b6N9SriKsJzHEvWlXeouc5Rcf1B0QrdID iEg9CroQ3MbqiXoCBpXVyFPddnB92W+zZRwnRi7wwjtTI4sEEKzuF0egUUDV9eB8vnmKe9xQ9CN I5RA3VgbqC3F8l/8liXG6TWiBAD7OgBbxHXmXxzwnpmtY/+rfS0Ip2eEHny+qryzYw2E8M8943o c3p3sq7rFUcuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:26:57 -0000 Right, well it is really just a case of "what do you want to achieve?" The point I raised originally was wrt the ERO. Firstly the ERO when the Path reaches the egress is not a lot of help, so there is magic mapping from the RRO required. But more importantly, if it is OK that the default position is that the two LSPs follow the same path, this is fine. OTOH, without putting an ERO with a single loose hop into the Reverse_LSP you have no way of telling the egress that it can perform its own routing choice on the reverse LSP. That seems clunky, but if it what the WG wants then that is OK - you'd just need to state it and explain which RRO sub-objects need to be stripped when creating the reverse path ERO (for example, labels and interfaces might not be suitable in all cases). I'm guessing, however, that the ERO is just the tip of the iceberg because we haven't gone through the task of looking at the full list of objects and deciding which ones should/could/would be copied. Maybe a way forward is: - If the object is in the Reverse_LSP it MUST be used - Otherwise the following information MUST be determined from the objects in the received Path message from the forward path LSP - TSpec - Session Attributes except for name - Admin_Status - ERO - Additionally any further information MAY be derived from the objects in the received Path message from the forward path LSP A > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 26 January 2015 15:05 > To: Rakesh Gandhi (rgandhi); adrian@olddog.co.uk; draft-ietf-teas-mpls-tp- > rsvpte-ext-associated-lsp.all@ietf.org > Cc: Alvaro Retana (aretana); teas@ietf.org > Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated- > lsp > > > On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian, > > > > Thanks for your inputs. > > > > If the initiator really needs a specific behaviour, and depending on it, > > it should signal the egress node via REVERSE_LSP. > > This is a key point. From an interoperability standpoint there needs to > be expected behavior. > > > IMO, MAY gives a reasonable choice for the egress node to do the right > > thing and if that is not what the initiator prefers, it can alter it by > > signaling REVERSE_LSP. > > > > To me "MAY" translates to the initiator not being able to rely on any > particular egress' behavior, so from a practical interoperability > standpoint this translates to me to be "don't expect anything to work > reliably without inclusion of the REVERSE_LSP object". So I really think > the proposed language is a bad idea. > > It seems to me that the options are: > (a) require the REVERSE_LSP Object and have it include all objects to be > used > -- I think this is over kill and optimizes for the special case > > (b) define predictable behavior when REVERSE_LSP Object isn't present > and when the REVERSE_LSP object doesn't contain all objects to be used. > -- I agree with Adrian's comment that an object enumeration based > approach is risky as it's unclear what happens with new objects. I think > this leads to a generic rule / directive which is how I read as the > intent of the text that lead to this question. Perhaps we can try to > tighten up the language so an egress knows what it SHOULD/MUST do while > an ingress can predict behavior? > > Lou > > > " > > If REVERSE_LSP Object is not present in the received Path message of > > the LSP, the egress node MAY use the LSP properties from the > > received LSP Path message to signal the LSP in the reverse direction > > (which may depend on the local policy). > > " > > > > Thanks, > > Rakesh > > > > > > > > > > On 2015-01-25 5:33 PM, "Adrian Farrel" wrote: > > > >> Hi Lou, Rakesh, all... > >> > >> [snip] > >> > >>>>> 5.3 has > >>>>> > >>>>> If REVERSE_LSP Object is not present in the received Path message > >>> of > >>>>> the LSP, the egress node SHOULD use the LSP properties from the > >>>>> received LSP Path message to signal the LSP in the reverse > >>> direction > >>>>> (which may depend on the local policy). > >>>>> > >>>>> This worries me. Do you mean that in the absence of a REVERSE_LSP > >>> object > >>>>> containing an ERO, the reverse LSP MUST be co-routed with the forward > >>>>> LSP? > >>>> > >>>> No. There will also be no (forward LSP) full ERO in the LSP > >>> either to > >>>> do that. > >>>> Does following work? > >>>> > >>>> If REVERSE_LSP Object is not present in the received Path message > >>> of > >>>> the LSP, the egress node MAY use the LSP properties from the > >>>> received LSP Path message to signal the LSP in the reverse > >>> direction > >>>> that MAY or MAY NOT follow the forward LSP path > >>>> (which may depend on the local policy). > >>> > >>> Humm, I think we should dig into this a bit more before making this > >>> change. > >>> > >>> Adrian, > >>> > >>> Do you have a specific concern with the existing text that you would > >>> like > >>> to see addressed ? > >>> > >>> I think the proposed revision is even less helpful. > >> > >> 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" > >> because it > >> implies you have a choice. > >> > >> 2. The ERO was just an example of what was worrying me. That is, that in > >> the > >> absence of sub-objects in the REVERSE_LSP object, the receiving end point > >> SHOULD (i.e., is strongly directed to unless there is an unusual > >> variation) use > >> the parameters from the forward direction to govern the reverse LSP. It > >> seems to > >> me that there are probably different classes of information that fit > into: > >> - MUST be in the REVERSE_LSP object or everything will fail (I believe > >> this is > >> the empty set) > >> - MUST be used from the forward LSP if not in the REVERSE_LSP object > >> - SHOULD be used from the forward LSP if not in the REVERSE_LSP object > >> - MAY be used from the forward LSP if not in the REVERSE_LSP object > >> - MUST NOT be used from the forward LSP if not in the REVERSE_LSP object > >> > >> TSpec is a simple example of SHOULD (although maybe the reverse path > TSpec > >> should be modelled on the FlowSpec that will was sent on the Resv?). > >> ERO (derived from the RRO) is either a MAY or a SHOULD depending on your > >> thought > >> pattern (some people think the default should be that the two LSPs fate > >> share). > >> The Session Name in the Session Attribute object seems like a MAY (noting > >> that > >> the name might already be in use). > >> The Alarm_Spec object looks like a MUST NOT. > >> Etc. > >> > >> I'm open to being persuaded that this collapses to one or two bullets. > >> But if it > >> is more than one bullet, I think there is work to be done to list it out. > >> And > >> that also worries me for extensibility - when I define a new object > >> carried in a > >> Path message, who is going to think about and document which class it > >> belongs > >> to? > >> Perhaps "MAY" is the vaguest and safest? > >> > >> Adrian > >> > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > From nobody Tue Jan 27 05:58:59 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB92F1A8739; Tue, 27 Jan 2015 05:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TENfgAKX4_nt; Tue, 27 Jan 2015 05:58:54 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD251A1B3F; Tue, 27 Jan 2015 05:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7430; q=dns/txt; s=iport; t=1422367134; x=1423576734; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8mhipKxDsp8JcmGIqYRRlmOOMhj0h90E+tMu/9gPjhc=; b=Wc3Lyv3LuOSjtF39e1ZlL7yH7VAdPwR7FKxhqmcMgBfTlA+p5mBKW5wX wjtJ7V4sUErfMtDDkF3pr6UBvJeDFsZvOIFsXSsoYk4ylNmObsQ75oBWK hj7E3e88558U6bBaNvxvFcsJd8zT5pybYztXziMon7ng5ORJNLbPMnJfj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFADSZx1StJV2Q/2dsb2JhbABUBoMGUlkExkwKhXECgSVDAQEBAQF9hAwBAQEEAQEBNy0HCwwGAQgRBAEBAR4JLgsUCQgCBAENBYgsDdQQAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPNRgrBwIEhCMFjm6JIYEVhUCIKoM9IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,474,1418083200"; d="scan'208";a="391464181" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jan 2015 13:58:53 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0RDwr8E003026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jan 2015 13:58:53 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 07:58:52 -0600 From: "Rakesh Gandhi (rgandhi)" To: "adrian@olddog.co.uk" , "'Lou Berger'" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" Thread-Topic: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp Thread-Index: AdA2UPHrR6Yon7iGSv+fwOmNm2NwiABoSkuAADAF+qYAG8A1AAAVsrWAAAzzzoAAKqfegP//1qcA Date: Tue, 27 Jan 2015 13:58:51 +0000 Message-ID: In-Reply-To: <040801d03a24$23b6f190$6b24d4b0$@olddog.co.uk> 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.231.231] Content-Type: text/plain; charset="us-ascii" Content-ID: <77EF164345341945A7E6A0FC7EC26DBC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 13:58:57 -0000 On 2015-01-27 6:26 AM, "Adrian Farrel" wrote: >Right, well it is really just a case of "what do you want to achieve?" > >The point I raised originally was wrt the ERO. >Firstly the ERO when the Path reaches the egress is not a lot of help, so >there >is magic mapping from the RRO required. >But more importantly, if it is OK that the default position is that the >two LSPs >follow the same path, this is fine. OTOH, without putting an ERO with a >single >loose hop into the Reverse_LSP you have no way of telling the egress that >it can >perform its own routing choice on the reverse LSP. That seems clunky, but >if it >what the WG wants then that is OK - you'd just need to state it and >explain >which RRO sub-objects need to be stripped when creating the reverse path >ERO >(for example, labels and interfaces might not be suitable in all cases). Hi Adrian, In the WG, it was agreed that for co-routed LSPs, GMPLS signaling should be used. This is why there is no mention of co-routed LSPs in this draft. Given this, and the complexity of using RRO to achieve co-routed LSPs, I prefer to keep the co-routed LSPs outside the scope of this draft. Thanks, Rakesh > >A > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: 26 January 2015 15:05 >> To: Rakesh Gandhi (rgandhi); adrian@olddog.co.uk; >>draft-ietf-teas-mpls-tp- >> rsvpte-ext-associated-lsp.all@ietf.org >> Cc: Alvaro Retana (aretana); teas@ietf.org >> Subject: Re: [Teas] AD review of >draft-ietf-teas-mpls-tp-rsvpte-ext-associated- >> lsp >>=20 >>=20 >> On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian, >> > >> > Thanks for your inputs. >> > >> > If the initiator really needs a specific behaviour, and depending on >>it, >> > it should signal the egress node via REVERSE_LSP. >>=20 >> This is a key point. From an interoperability standpoint there needs to >> be expected behavior. >>=20 >> > IMO, MAY gives a reasonable choice for the egress node to do the right >> > thing and if that is not what the initiator prefers, it can alter it >>by >> > signaling REVERSE_LSP. >> > >>=20 >> To me "MAY" translates to the initiator not being able to rely on any >> particular egress' behavior, so from a practical interoperability >> standpoint this translates to me to be "don't expect anything to work >> reliably without inclusion of the REVERSE_LSP object". So I really think >> the proposed language is a bad idea. >>=20 >> It seems to me that the options are: >> (a) require the REVERSE_LSP Object and have it include all objects to be >> used >> -- I think this is over kill and optimizes for the special case >>=20 >> (b) define predictable behavior when REVERSE_LSP Object isn't present >> and when the REVERSE_LSP object doesn't contain all objects to be used. >> -- I agree with Adrian's comment that an object enumeration based >> approach is risky as it's unclear what happens with new objects. I think >> this leads to a generic rule / directive which is how I read as the >> intent of the text that lead to this question. Perhaps we can try to >> tighten up the language so an egress knows what it SHOULD/MUST do while >> an ingress can predict behavior? >>=20 >> Lou >>=20 >> > " >> > If REVERSE_LSP Object is not present in the received Path message of >> > the LSP, the egress node MAY use the LSP properties from the >> > received LSP Path message to signal the LSP in the reverse direction >> > (which may depend on the local policy). >> > " >> > >> > Thanks, >> > Rakesh >> > >> > >> > >> > >> > On 2015-01-25 5:33 PM, "Adrian Farrel" wrote: >> > >> >> Hi Lou, Rakesh, all... >> >> >> >> [snip] >> >> >> >>>>> 5.3 has >> >>>>> >> >>>>> If REVERSE_LSP Object is not present in the received Path >>message >> >>> of >> >>>>> the LSP, the egress node SHOULD use the LSP properties from the >> >>>>> received LSP Path message to signal the LSP in the reverse >> >>> direction >> >>>>> (which may depend on the local policy). >> >>>>> >> >>>>> This worries me. Do you mean that in the absence of a REVERSE_LSP >> >>> object >> >>>>> containing an ERO, the reverse LSP MUST be co-routed with the >>forward >> >>>>> LSP? >> >>>> >> >>>> No. There will also be no (forward LSP) full ERO in the LSP >> >>> either to >> >>>> do that. >> >>>> Does following work? >> >>>> >> >>>> If REVERSE_LSP Object is not present in the received Path >>message >> >>> of >> >>>> the LSP, the egress node MAY use the LSP properties from the >> >>>> received LSP Path message to signal the LSP in the reverse >> >>> direction >> >>>> that MAY or MAY NOT follow the forward LSP path >> >>>> (which may depend on the local policy). >> >>> >> >>> Humm, I think we should dig into this a bit more before making this >> >>> change. >> >>> >> >>> Adrian, >> >>> >> >>> Do you have a specific concern with the existing text that you would >> >>> like >> >>> to see addressed ? >> >>> >> >>> I think the proposed revision is even less helpful. >> >> >> >> 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" >> >> because it >> >> implies you have a choice. >> >> >> >> 2. The ERO was just an example of what was worrying me. That is, >>that in >> >> the >> >> absence of sub-objects in the REVERSE_LSP object, the receiving end >>point >> >> SHOULD (i.e., is strongly directed to unless there is an unusual >> >> variation) use >> >> the parameters from the forward direction to govern the reverse LSP. >>It >> >> seems to >> >> me that there are probably different classes of information that fit >> into: >> >> - MUST be in the REVERSE_LSP object or everything will fail (I >>believe >> >> this is >> >> the empty set) >> >> - MUST be used from the forward LSP if not in the REVERSE_LSP object >> >> - SHOULD be used from the forward LSP if not in the REVERSE_LSP >>object >> >> - MAY be used from the forward LSP if not in the REVERSE_LSP object >> >> - MUST NOT be used from the forward LSP if not in the REVERSE_LSP >>object >> >> >> >> TSpec is a simple example of SHOULD (although maybe the reverse path >> TSpec >> >> should be modelled on the FlowSpec that will was sent on the Resv?). >> >> ERO (derived from the RRO) is either a MAY or a SHOULD depending on >>your >> >> thought >> >> pattern (some people think the default should be that the two LSPs >>fate >> >> share). >> >> The Session Name in the Session Attribute object seems like a MAY >>(noting >> >> that >> >> the name might already be in use). >> >> The Alarm_Spec object looks like a MUST NOT. >> >> Etc. >> >> >> >> I'm open to being persuaded that this collapses to one or two >>bullets. >> >> But if it >> >> is more than one bullet, I think there is work to be done to list it >>out. >> >> And >> >> that also worries me for extensibility - when I define a new object >> >> carried in a >> >> Path message, who is going to think about and document which class it >> >> belongs >> >> to? >> >> Perhaps "MAY" is the vaguest and safest? >> >> >> >> Adrian >> >> >> > >> > _______________________________________________ >> > Teas mailing list >> > Teas@ietf.org >> > https://www.ietf.org/mailman/listinfo/teas >> > > From nobody Tue Jan 27 06:04:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B111A1B3F for ; Tue, 27 Jan 2015 06:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 3tz5a64pBW7q for ; Tue, 27 Jan 2015 06:04:32 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 0E76C1A1A6E for ; Tue, 27 Jan 2015 06:04:31 -0800 (PST) Received: (qmail 32686 invoked by uid 0); 27 Jan 2015 14:04:23 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 27 Jan 2015 14:04:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id l24F1p0012SSUrH0124J2b; Tue, 27 Jan 2015 07:04:23 -0700 X-Authority-Analysis: v=2.1 cv=NPZGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=0OijzeEylCvssALmQkcA:9 a=LKxQUhdRqHPD_gyB:21 a=M8umvk1LitUBdM2p:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=MSVSg+phf4FiISuFVHnP1eWsfUrCLcqHQKiLkN3vVjs=; b=UVFdF1HIEPl2sVehhedEDSrwQuHhT4pabSicIBGEMOCqwXWJAi3/2IWcKMLAoFS9wvBVOgndB8ynrIjIeomFlEndpMZHkOJt9hohkc532OUv7RR1fh/yBJbdCs/3CZ15; Received: from box313.bluehost.com ([69.89.31.113]:56826 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YG6kY-0000er-T1; Tue, 27 Jan 2015 07:04:15 -0700 Message-ID: <54C79ADB.3090009@labn.net> Date: Tue, 27 Jan 2015 09:04:11 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" , "adrian@olddog.co.uk" , "draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp.all@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "Alvaro Retana \(aretana\)" , "teas@ietf.org" Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 14:04:35 -0000 Rakesh, Let's take a stab (off line) at language that addresses Adrian's comment and captures (our understanding) of the intent of the existing language, and then pass it around for review by all. If you can take a stab at it and send it to me that would be best. Adrian, Give us a little time, say a day or two to get back to you. Lou On 01/27/2015 08:58 AM, Rakesh Gandhi (rgandhi) wrote: > > > On 2015-01-27 6:26 AM, "Adrian Farrel" wrote: > >> Right, well it is really just a case of "what do you want to achieve?" >> >> The point I raised originally was wrt the ERO. >> Firstly the ERO when the Path reaches the egress is not a lot of help, so >> there >> is magic mapping from the RRO required. >> But more importantly, if it is OK that the default position is that the >> two LSPs >> follow the same path, this is fine. OTOH, without putting an ERO with a >> single >> loose hop into the Reverse_LSP you have no way of telling the egress that >> it can >> perform its own routing choice on the reverse LSP. That seems clunky, but >> if it >> what the WG wants then that is OK - you'd just need to state it and >> explain >> which RRO sub-objects need to be stripped when creating the reverse path >> ERO >> (for example, labels and interfaces might not be suitable in all cases). > > > Hi Adrian, > > In the WG, it was agreed that for co-routed LSPs, GMPLS signaling should > be used. This is why there is no mention of co-routed LSPs in this draft. > Given this, and the complexity of using RRO to achieve co-routed LSPs, I > prefer to keep the co-routed LSPs outside the scope of this draft. > > Thanks, > Rakesh > > > > > > >> >> A >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: 26 January 2015 15:05 >>> To: Rakesh Gandhi (rgandhi); adrian@olddog.co.uk; >>> draft-ietf-teas-mpls-tp- >>> rsvpte-ext-associated-lsp.all@ietf.org >>> Cc: Alvaro Retana (aretana); teas@ietf.org >>> Subject: Re: [Teas] AD review of >> draft-ietf-teas-mpls-tp-rsvpte-ext-associated- >>> lsp >>> >>> >>> On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian, >>>> >>>> Thanks for your inputs. >>>> >>>> If the initiator really needs a specific behaviour, and depending on >>> it, >>>> it should signal the egress node via REVERSE_LSP. >>> >>> This is a key point. From an interoperability standpoint there needs to >>> be expected behavior. >>> >>>> IMO, MAY gives a reasonable choice for the egress node to do the right >>>> thing and if that is not what the initiator prefers, it can alter it >>> by >>>> signaling REVERSE_LSP. >>>> >>> >>> To me "MAY" translates to the initiator not being able to rely on any >>> particular egress' behavior, so from a practical interoperability >>> standpoint this translates to me to be "don't expect anything to work >>> reliably without inclusion of the REVERSE_LSP object". So I really think >>> the proposed language is a bad idea. >>> >>> It seems to me that the options are: >>> (a) require the REVERSE_LSP Object and have it include all objects to be >>> used >>> -- I think this is over kill and optimizes for the special case >>> >>> (b) define predictable behavior when REVERSE_LSP Object isn't present >>> and when the REVERSE_LSP object doesn't contain all objects to be used. >>> -- I agree with Adrian's comment that an object enumeration based >>> approach is risky as it's unclear what happens with new objects. I think >>> this leads to a generic rule / directive which is how I read as the >>> intent of the text that lead to this question. Perhaps we can try to >>> tighten up the language so an egress knows what it SHOULD/MUST do while >>> an ingress can predict behavior? >>> >>> Lou >>> >>>> " >>>> If REVERSE_LSP Object is not present in the received Path message of >>>> the LSP, the egress node MAY use the LSP properties from the >>>> received LSP Path message to signal the LSP in the reverse direction >>>> (which may depend on the local policy). >>>> " >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> >>>> >>>> On 2015-01-25 5:33 PM, "Adrian Farrel" wrote: >>>> >>>>> Hi Lou, Rakesh, all... >>>>> >>>>> [snip] >>>>> >>>>>>>> 5.3 has >>>>>>>> >>>>>>>> If REVERSE_LSP Object is not present in the received Path >>> message >>>>>> of >>>>>>>> the LSP, the egress node SHOULD use the LSP properties from the >>>>>>>> received LSP Path message to signal the LSP in the reverse >>>>>> direction >>>>>>>> (which may depend on the local policy). >>>>>>>> >>>>>>>> This worries me. Do you mean that in the absence of a REVERSE_LSP >>>>>> object >>>>>>>> containing an ERO, the reverse LSP MUST be co-routed with the >>> forward >>>>>>>> LSP? >>>>>>> >>>>>>> No. There will also be no (forward LSP) full ERO in the LSP >>>>>> either to >>>>>>> do that. >>>>>>> Does following work? >>>>>>> >>>>>>> If REVERSE_LSP Object is not present in the received Path >>> message >>>>>> of >>>>>>> the LSP, the egress node MAY use the LSP properties from the >>>>>>> received LSP Path message to signal the LSP in the reverse >>>>>> direction >>>>>>> that MAY or MAY NOT follow the forward LSP path >>>>>>> (which may depend on the local policy). >>>>>> >>>>>> Humm, I think we should dig into this a bit more before making this >>>>>> change. >>>>>> >>>>>> Adrian, >>>>>> >>>>>> Do you have a specific concern with the existing text that you would >>>>>> like >>>>>> to see addressed ? >>>>>> >>>>>> I think the proposed revision is even less helpful. >>>>> >>>>> 1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" >>>>> because it >>>>> implies you have a choice. >>>>> >>>>> 2. The ERO was just an example of what was worrying me. That is, >>> that in >>>>> the >>>>> absence of sub-objects in the REVERSE_LSP object, the receiving end >>> point >>>>> SHOULD (i.e., is strongly directed to unless there is an unusual >>>>> variation) use >>>>> the parameters from the forward direction to govern the reverse LSP. >>> It >>>>> seems to >>>>> me that there are probably different classes of information that fit >>> into: >>>>> - MUST be in the REVERSE_LSP object or everything will fail (I >>> believe >>>>> this is >>>>> the empty set) >>>>> - MUST be used from the forward LSP if not in the REVERSE_LSP object >>>>> - SHOULD be used from the forward LSP if not in the REVERSE_LSP >>> object >>>>> - MAY be used from the forward LSP if not in the REVERSE_LSP object >>>>> - MUST NOT be used from the forward LSP if not in the REVERSE_LSP >>> object >>>>> >>>>> TSpec is a simple example of SHOULD (although maybe the reverse path >>> TSpec >>>>> should be modelled on the FlowSpec that will was sent on the Resv?). >>>>> ERO (derived from the RRO) is either a MAY or a SHOULD depending on >>> your >>>>> thought >>>>> pattern (some people think the default should be that the two LSPs >>> fate >>>>> share). >>>>> The Session Name in the Session Attribute object seems like a MAY >>> (noting >>>>> that >>>>> the name might already be in use). >>>>> The Alarm_Spec object looks like a MUST NOT. >>>>> Etc. >>>>> >>>>> I'm open to being persuaded that this collapses to one or two >>> bullets. >>>>> But if it >>>>> is more than one bullet, I think there is work to be done to list it >>> out. >>>>> And >>>>> that also worries me for extensibility - when I define a new object >>>>> carried in a >>>>> Path message, who is going to think about and document which class it >>>>> belongs >>>>> to? >>>>> Perhaps "MAY" is the vaguest and safest? >>>>> >>>>> Adrian >>>>> >>>> >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas >>>> >> > > From nobody Tue Jan 27 12:09:59 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2D1A6FF0; Tue, 27 Jan 2015 12:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 1aVm6-wcOVsD; Tue, 27 Jan 2015 12:01:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8BD1A8A46; Tue, 27 Jan 2015 12:01:39 -0800 (PST) Received: from hannes-mba.local (193.110.55.11) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.59.20; Tue, 27 Jan 2015 20:01:16 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 50A73D6E580; Tue, 27 Jan 2015 21:01:01 +0100 (CET) Date: Tue, 27 Jan 2015 21:01:01 +0100 From: Hannes Gredler To: Lizhenbin Message-ID: <20150127200101.GA21477@hannes-mba.local> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.11] X-ClientProxiedBy: DB4PR06CA0018.eurprd06.prod.outlook.com (25.160.40.146) To DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR05MB447; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB447; X-Forefront-PRVS: 046985391D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(37854004)(24454002)(53754006)(83506001)(46102003)(77096005)(98436002)(92566002)(62966003)(76176999)(54356999)(122386002)(2950100001)(47776003)(19580395003)(33656002)(77156002)(97736003)(76506005)(122856001)(15975445007)(23726002)(40100003)(86362001)(46406003)(110136001)(87976001)(19580405001)(50466002)(50986999)(68736005)(97756001)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:hannes-mba.local; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2015 20:01:16.6798 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB447 Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 12:09:57 -0800 Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:01:48 -0000 only can speak for IS-IS - afaik the Trill extensions gave us a way of signaling the MTU of a link ... so what we could do is to advertise the MTU for each adjacency and implement proper fragmentation at the TE tunnel ingress. /hannes On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote: | Hi all authors of segment routing, | | This is the seventh commens. The issues proposed here are for both SR-TE | path and SR-BE path. | | | | 1 1 1 1 | S11-----------S12----------S13---------S14---------S15 | | | | | | | 1| 1| 1| 1| 1| | | | | | | | S21-----------S22----------S23---------S24---------S25 | 4 4 4 4 | | | | Still take the topology in the comment 6 as the example. No matter the | loose explicit path or | | the strict explicit path for the loose hop, assume the MTU of the | interface is the same, | | since the depth of the label stacks for the primary path and the backup | path are different. | | There is the risk that the effetive payload may transmit through the | primary path, but may be | | fragmented or dropped in the backup path. As the difference between the | label stacks of the | | primary path and the backup path increase, the risk will increase. | | | | From the case, we can deduce that the risk may exists for any scenarios in | which the same traffic | | may switch from one SR path to the other SR path. The SR path includes | SR-TE path such as MPLS TE | | hotstandby/reoptimization and SR-BE path such as TI-FRR. | | | | Besides above issues, LDP/RSVP-TE can support the path MTU to track the | MTU informaiton along the | | LSP through signalling. Then the reasonable MTU info will be adopted in | the ingress node. For both | | SR-TE path (if PCE is not used) and SR-BE path, since there is no | signalling to advertise | | the information. How to implement the feature? Or there maybe the risk | that the packet may be | | dropped by the nodes along the LSP. | | | | | | | | Regards, | | Robin | _______________________________________________ | spring mailing list | spring@ietf.org | https://www.ietf.org/mailman/listinfo/spring From nobody Tue Jan 27 21:48:58 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06991A0021; Tue, 27 Jan 2015 21:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 769qS7dtsIlr; Tue, 27 Jan 2015 21:48:50 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019771A001B; Tue, 27 Jan 2015 21:48:49 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.201.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 96E4418029FB; Wed, 28 Jan 2015 06:48:44 +0100 (CET) Message-ID: <54C87836.7020800@pi.nu> Date: Wed, 28 Jan 2015 13:48:38 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "teas-chairs@ietf.org" , draft-ietf-mpls-te-express-path@tools.ietf.org, TEAS WG Subject: [Teas] future for draft-ietf-mpls-te-express-path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 05:48:52 -0000 Working Groups, The MPLS working group has an informal expired draft - draft-ietf-mpls- te-express-path. When working drafts expire the wg chair check why this is so and take the actions needed. In this case the result was - the authors are interested to revive the document; since - the query gave the result that at least some find this informational document useful; however - it seems that after the re-tuning of the rtg area this document no longer belongs in the mpls working but in teas. The teas chairs need to decide what to do with the document, but if you belong to those who think it is useful it would be good if you said so on the list(s). /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jan 28 03:06:15 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365801A1A31; Wed, 28 Jan 2015 03:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZfbriHGV6ouX; Wed, 28 Jan 2015 03:06:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5119D1A1A2D; Wed, 28 Jan 2015 03:06:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON01810; Wed, 28 Jan 2015 11:06:08 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 11:06:07 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 19:06:02 +0800 From: Lizhenbin To: Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIE= Date: Wed, 28 Jan 2015 11:06:01 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> In-Reply-To: <20150127200101.GA21477@hannes-mba.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [Teas] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNS?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:06:14 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpJIGhhdmUgZXZlciB0aG91Z2h0IGFib3V0IHRoZSBwb3NzaWJsZSBzb2x1 dGlvbnMgYmFzZWQgb24gdGhlIGZsb29kZWQgTVRVIGluZm9ybWF0aW9uIHRocm91Z2ggSUdQLg0K DQpUaGVyZSBhcmUgc3RpbGwgdHdvIHBvc3NpYmxlIGlzc3VlczoNCg0KMS4gSW50ZXItYXJlYSBm b3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNlIHRoZSBJR1AgZXh0ZW5z aW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLg0KDQoyLiBGb3IgU1ItQkUgcGF0aCwgaXQg aGFzIHRvIGludHJvZHVjZSB0aGUgVEUtbGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRpb24g YXQgdGhlIGluZ3Jlc3Mgbm9kZS4NCg0KDQoNCk15IGNvbmNlcm4gaXMgbm90IGp1c3QgZm9yIHRo ZSBwb3NzaWJsZSBzb2x1dGlvbnMsIGJ1dCB0byBleHBsb3JlIHRoZSBlc3NlbmNlIG9mIFNSIHdo aWNoIG1heSBoYXMgbXVjaA0KDQplZmZlY3Qgb24gaXRzIGRlcGxveW1lbnQgY29tcGFyaW5nIHdp dGggdGhlIGV4aXN0aW5nIE1QTFMgcHJvdG9jb2wuIEl0IHdpbGwgYmUgZXhwbGFpbmVkIGluDQoN CnRoZSBuZXh0IGNvbW1lbnRzLg0KDQoNCg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoN Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBIYW5uZXMgR3JlZGxlciBbaGFubmVzQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHU wjI4yNUgNDowMQ0KytW8/sjLOiBMaXpoZW5iaW4NCrOty806IHNwcmluZ0BpZXRmLm9yZzsgbXBs c0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50 cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpvbmx5IGNh biBzcGVhayBmb3IgSVMtSVMgLQ0KYWZhaWsgdGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBh IHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBvZiBhIGxpbmsgLi4uDQoNCnNvIHdoYXQgd2UgY291 bGQgZG8gaXMgdG8gYWR2ZXJ0aXNlIHRoZSBNVFUgZm9yIGVhY2ggYWRqYWNlbmN5IGFuZCBpbXBs ZW1lbnQNCnByb3BlciBmcmFnbWVudGF0aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy4NCg0K L2hhbm5lcw0KDQpPbiBUdWUsIEphbiAyNywgMjAxNSBhdCAxMToyNDoyM0FNICswMDAwLCBMaXpo ZW5iaW4gd3JvdGU6DQp8ICAgIEhpIGFsbCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGluZywNCnwN CnwgICAgVGhpcyBpcyB0aGUgc2V2ZW50aCBjb21tZW5zLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhl cmUgYXJlIGZvciBib3RoIFNSLVRFDQp8ICAgIHBhdGggYW5kIFNSLUJFIHBhdGguDQp8DQp8DQp8 DQp8ICAgICAgICAgICAgIDEgICAgICAgICAgICAgIDEgICAgICAgICAgIDEgICAgICAgICAgICAx DQp8ICAgICAgUzExLS0tLS0tLS0tLS1TMTItLS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0LS0tLS0t LS0tUzE1DQp8ICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgIHwNCnwgICAgICAxfCAgICAgICAgICAgIDF8ICAgICAgICAgICAxfCAgICAgICAg ICAxfCAgICAgICAgICAxfA0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg ICAgICAgICB8ICAgICAgICAgICB8DQp8ICAgICAgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0t UzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1DQp8ICAgICAgICAgICAgIDQgICAgICAgICAgICAg IDQgICAgICAgICAgIDQgICAgICAgICAgICA0DQp8DQp8DQp8DQp8ICAgIFN0aWxsIHRha2UgdGhl IHRvcG9sb2d5IGluIHRoZSBjb21tZW50IDYgYXMgdGhlIGV4YW1wbGUuIE5vIG1hdHRlciB0aGUN CnwgICAgbG9vc2UgZXhwbGljaXQgcGF0aCBvcg0KfA0KfCAgICB0aGUgc3RyaWN0IGV4cGxpY2l0 IHBhdGggZm9yIHRoZSBsb29zZSBob3AsIGFzc3VtZSB0aGUgTVRVIG9mIHRoZQ0KfCAgICBpbnRl cmZhY2UgaXMgdGhlIHNhbWUsDQp8DQp8ICAgIHNpbmNlIHRoZSBkZXB0aCBvZiB0aGUgbGFiZWwg c3RhY2tzIGZvciB0aGUgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwDQp8ICAgIHBhdGggYXJl IGRpZmZlcmVudC4NCnwNCnwgICAgVGhlcmUgaXMgdGhlIHJpc2sgdGhhdCB0aGUgZWZmZXRpdmUg cGF5bG9hZCBtYXkgdHJhbnNtaXQgdGhyb3VnaCB0aGUNCnwgICAgcHJpbWFyeSBwYXRoLCBidXQg bWF5IGJlDQp8DQp8ICAgIGZyYWdtZW50ZWQgb3IgZHJvcHBlZCBpbiB0aGUgYmFja3VwIHBhdGgu IEFzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQp8ICAgIGxhYmVsIHN0YWNrcyBvZiB0aGUN CnwNCnwgICAgcHJpbWFyeSBwYXRoIGFuZCB0aGUgYmFja3VwIHBhdGggaW5jcmVhc2UsIHRoZSBy aXNrIHdpbGwgaW5jcmVhc2UuDQp8DQp8DQp8DQp8ICAgIEZyb20gdGhlIGNhc2UsIHdlIGNhbiBk ZWR1Y2UgdGhhdCB0aGUgcmlzayBtYXkgZXhpc3RzIGZvciBhbnkgc2NlbmFyaW9zIGluDQp8ICAg IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWMNCnwNCnwgICAgIG1heSBzd2l0Y2ggZnJvbSBvbmUgU1Ig cGF0aCB0byB0aGUgb3RoZXIgU1IgcGF0aC4gVGhlIFNSIHBhdGggaW5jbHVkZXMNCnwgICAgU1It VEUgcGF0aCBzdWNoIGFzIE1QTFMgVEUNCnwNCnwgICAgaG90c3RhbmRieS9yZW9wdGltaXphdGlv biBhbmQgU1ItQkUgcGF0aCBzdWNoIGFzIFRJLUZSUi4NCnwNCnwNCnwNCnwgICAgQmVzaWRlcyBh Ym92ZSBpc3N1ZXMsIExEUC9SU1ZQLVRFIGNhbiBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFj ayB0aGUNCnwgICAgTVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZQ0KfA0KfCAgICBMU1AgdGhyb3Vn aCBzaWduYWxsaW5nLiBUaGVuIHRoZSByZWFzb25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRl ZCBpbg0KfCAgICB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90aA0KfA0KfCAgICAgU1ItVEUgcGF0 aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQgU1ItQkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8N CnwgICAgc2lnbmFsbGluZyB0byBhZHZlcnRpc2UNCnwNCnwgICAgdGhlIGluZm9ybWF0aW9uLiBI b3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJlPyBPciB0aGVyZSBtYXliZSB0aGUgcmlzaw0KfCAg ICB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQp8DQp8ICAgIGRyb3BwZWQgYnkgdGhlIG5vZGVzIGFs b25nIHRoZSBMU1AuDQp8DQp8DQp8DQp8DQp8DQp8DQp8DQp8ICAgIFJlZ2FyZHMsDQp8DQp8ICAg IFJvYmluDQoNCnwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnwgc3ByaW5nIG1haWxpbmcgbGlzdA0KfCBzcHJpbmdAaWV0Zi5vcmcNCnwgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hannes,

I have ever thought about the possible solutions = based on the flooded MTU information through IGP.

There are still two possible issues:

1. Inter-area for SR-TE path: Maybe we not only i= ntroduce the IGP extensions, but also PCEP extensions.

2. For SR-BE path, it has to introduce the TE-lik= e end-to-end path calculation at the ingress node.

 

My concern is not just for the possible solutions= , but to explore the essence of SR which may has much

effect on its deployment comparing wit= h the existing MPLS protocol. It will be explained in

the next comments.

 

 

Regards,

Robin

 

 

 



________________________________________
=B7=A2=BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challeng= es for SR

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org
| https://www.ietf.org/mailman/listinfo/spring

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845nkgeml506mbxchi_-- From nobody Wed Jan 28 03:31:22 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3D91A1AC8; Wed, 28 Jan 2015 03:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nuF5q09_p7rZ; Wed, 28 Jan 2015 03:31:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C4B1A1A97; Wed, 28 Jan 2015 03:30:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRV25484; Wed, 28 Jan 2015 11:30:45 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 11:30:44 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 19:30:36 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR Thread-Index: AdA66yE5259u7U/sTZCfhnmR4h4dmw== Date: Wed, 28 Jan 2015 11:30:35 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [Teas] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:31:18 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgZWln aHRoIGNvbW1lbnRzLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhlcmUgYXBwbHkgdG8gYm90aCBTUi1U RSBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KDQoNCg0KRm9yIExEUCBhbmQgUlNWUC1URSwgdGhlcmUg aXMgdGhlIGxvb3AgcHJldmVudGlvbiBtZWNoYW5pc20gd2hlbiBzZXR1cCBMU1AuIEZvciB0aGUg U1IsIHRoZSBTUiBwYXRoIGlzIGFsd2F5cw0KDQpzZXR1cCBhdCB0aGUgaW5ncmVzcyBub2RlLiBJ dCBpcyBkaWZmaWN1bHQgdG8gZGV0ZWN0IHRoZSBwb3NzaWJsZSBsb29wIGluIHRoZSBuZXR3b3Jr LiBGb3IgZXhhbXBsZSwgaWYgdGhlDQoNCm1pY3JvbG9vcCBvZiByb3V0ZSBoYXBwZW5zLCB0aGUg bG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlzbSB3aWxsIHByZXZlbnQgTERQIHRvIHNldHVwIExTUC4g QnV0IGZvciB0aGUgc2VnbWVudA0KDQpyb3V0aW5nLCBvbmNlIHRoZSBpbmdyZXNzIG5vZGUgZG93 bmxvYWRzIHRoZSBmb3J3YXJkaW5nIGVudHJ5IGFuZCB0aGUgdHJhZmZpYyB3aWxsIGV4cGVyaWVu Y2UgdGhlIG1pY3JvbG9vcC4NCg0KSG93IGNhbiBTUiB0byBjb3BlIHdpdGggdGhlIGlzc3VlIG9y IGp1c3QgbGVhdmUgaXQgYXMgdGhlIHRyYWRpdGlvbmFsIHJvdXRpbmc/DQoNCg0KDQpGb3IgTERQ IGFuZCBSU1ZQLVRFLCB0aGVyZSBpcyB0aGUgZXJyb3Igbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBi YXNlZCBvbiB0aGUgTERQIG5vdGlmaWNhdGlvbiBtZXNzYWdlIG9yIHRoZQ0KDQpSU1ZQLVRFIFBh dGhFcnIvUmVzdiBtZXNzYWdlcy4gQmFzZWQgb24gdGhlIGVycm9yIG5vdGlmaWNhdGlvbiwgdGhl IG5vZGVzIGFsb25nIHRoZSBMU1AgY2FuIHRha2UgcG9zc2libGUNCg0KYWN0aW9ucyBhZ2FpbnN0 IHRoZSBwb3NzaWJsZSBlcnJvcnMuIEJ1dCBmb3IgU1IsIHRoZXJlIGlzIG5vIHN1Y2ggaW5mb3Jt YXRpb24gY29tbXVuaWNhdGVkIGFtb25nIHRoZSBub2Rlcw0KDQphbG9uZyB0aGUgU1IgUGF0aC4g VGhlIHJlc3VsdCB3aWxsIGJlIHRoYXQgb25jZSB0aGUgcGFja2V0IGlzIGZvcndhcmRlZCBieSB0 aGUgaW5ncmVzcyBub2RlLCB0aGV5IG1heQ0KDQpleHBlcmllbmNlIHRoZSBwb3NzaWJsZSBlcnJv cnMgd2hpY2ggbWF5IGJlIHByZXZlbnRlZCBieSB0aGUgbmVnb3RpYXRpb24gaW4gdGhlIGNvbnRy b2wgcGxhbmUuDQoNCg0KDQpGcm9tIHRoZSBwcmV2aW91cyBjb21tZW50cywgd2UgY2FuIHNlZSB0 aGF0IGluIHRoZSB0cmFkaXRpb25hbCBMU1AsIHRoZSBMU1Agc2V0dXAgaXMgbmVnb3RpYXRlZCB0 aHJvdWdoDQoNCnRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIHVwc3RyZWFtIG5vZGUgYW5kIHRo ZSBkb3duc3RyZWFtIG5vZGUuIER1cmluZyB0aGUgbmVnb3RpYXRpb24sIGl0IGlzIG5vdCBvbmx5 IHRvDQoNCnNldCB1cCB0aGUgZm9yd2FyZGluZyB0aGUgZW50cnkgZm9yIHRoZSBwdXJwb3NlIG9m IHJlYWNoYWJsaXR5LCBidXQgYWxzbyBpbmNsdWRlcyBtYW55IGFzcGVjdHMgKEkgY2FsbCB0aGVt DQoNCmFzIHRoZSBvcGVyYXRpb24gYW5kIG1haW50ZW5lbmNlIG9mIHRoZSBMU1AuIEhvcGUgaXQg aXMgYXBwcm9wcmlhdGUuICkgc3VjaCBhcyB0aGUgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHkNCg0K dmVyaWZpY2F0aW9uLCB0aGUgbG9vcCBwcmV2ZW50aW9uLCBwYXRoIE1UVSwgbmVnb3RpYXRpb24s IHBhdGggcmVjb3JkaW5nLCBlcnJvciBub3RpZmljYXRpb24gYW5kIGhhbmRsaW5nLA0KDQpldGMu IFRob3VnaCBTUiBhbHdheXMgcHJvcG9zZXMgaXRzIGFkdmFudGFnZSwgaW4gbXkgb3Bpbmlvbiwg dGhlc2UgYWR2YW50YWdlcyBhcmUgZnJvbSB0aGUgcmVhY2hhYmlsaXR5DQoNCnBhcnQgc3VjaCBh cyB0aGUgYWR2YW50YWdlIHRoYXQgdGhlIGxhYmVsIHN0YXRjayBpbiB0aGUgaW5ncmVzcyBub2Rl IHJlZHVjZXMgdGhlIHN0YXRlcyBpbiB0aGUgbmV0d29yay4NCg0KQnV0IHRoZSByZXF1aXJlbWVu dHMgb2YgdGhlIG9wZXJhdGlvbmFsIGFuZCBtYWludGVuYW5jZSBmb3IgdGhlIHRyYWRpdGlvbmFs IExTUCBzdGlsbCBleGlzdC4gVGFraW5nIGludG8NCg0KYWNjb3VudCB0aGF0IHRoZSBmbG9vZGlu ZyBtb2RlIG9mIHRoZSBJR1AsIGl0IHN0b3BzIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhl IG5vZGVzIGFsb25nIHRoZSBwYXRoLA0KDQp0aGUgd29yayBtYXkgYmVjb21lIG1vcmUgY29tcGxl eC4gQWNjb3JkaW5nIHRvIHRoZSBwYXN0IGV4cGVyaWVuY2UsIHRoZSBwb3NzaWJsZSB3YXlzIEkg Y291bGQgdGhpbmsgb3V0IGFyZQ0KDQphcyBmb2xsb3dzOg0KMSkgRGVwZW5kIG9uIHRoZSB0aGly ZC1wYXJ0eSBtZWNoYW5pc21zLiBCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGVyZSBtYXkgaW52 b2x2ZSBtb3JlIG1lY2hhbmlzbXMgYW5kIHRoZXJlDQoNCm1heSBiZSBubyBtZWNoYW5pc21zLiBG b3IgZXhhbXBsZSwgTFNQIFBpbmcgY2FuIGJlIGFkb3B0ZWQgdG8gY2hlY2sgdGhlIGVuZC10by1l bmQgY29ubmVjdGl2aXR5IG9yIGxvb3AgZm9yDQoNCnRoZSBTUi1CRSBwYXRoLCBidXQgaXQgY2Fu bm90IGJlIHVzZWQgZm9yIHBhdGggTVRVIG5lZ290aWF0aW9uLiBGb3IgdGhlIGVuZC10by1lbmQg cGF0aCByZWNvcmRpbmcsIExTUCBUcmFjZXJ0DQoNCm1heSBoYXZlIHRvIGJlIGludHJvZHVjZWQu IElmIHRoZXNlIHJlcXVpcmVtZW50cyBhbmQgbWVjaGFuaXNtcyBhcmUgY29uc2lkZXJlZCwgaXQg bWVhbnMgU1IgZG9lcyBub3QgcmVkdWNlDQoNCnRoZSBjb21wZXhpdHkuIEluc3RlYWQgaXQganVz dCB0cmFuc2ZlcnMgbW9yZSBjb21wbGV4aXR5IHRvIHRoZSBvdGhlciBwb3NzaWJsZSBzaWduYWxs aW5ncy4NCjIpIERlcGVuZCBvbiBvbmUgbm9kZXMgdG8gaW1wbGVtZW50IHRoZSBwb3NzaWJsZSBm dW5jdGlvbnMuIEZvciBleGFtcGxlLCBmb3IgU1ItVEUgcGF0aCwgaXQgY2FuIGRlcGVuZCBvbiB0 aGUNCg0KUENFIG9yIHRoZSBpbmdyZXNzIG5vZGUgdG8gY29sbGVjdCBhbGwgcGF0aCBpbmZvIHBy b3Bvc2VkIGJ5IHBhdGggcmVjb3JkaW5nIG9yIGV2ZW4gcGF0aCBNVFUgbmVnb3RpYXRpb24uIEV2 ZW4gc28sDQoNCnRoZXJlIGlzIHN0aWxsIHNvbWUgZHJhd2JhY2tzIGZvciBzb21lIHNjZW5hcmlv cyBpZiBvbmx5IGRlcGVuZCBvbiB0aGUgaW5ncmVzcyBub2RlLiBNb3Jlb3ZlciB0aGVzZSBtZXRo b2RzDQpjYW5ub3QgYXBwbHkgdG8gU1ItQkUgcGF0aC5JZiB0aGUgcG9zc2libGUgd29yayBpcyBk b25lIHRocm91Z2ggdGhlIGluZ3Jlc3Mgbm9kZSwgaXQgd2lsbCBiZWdpbiB0byBjaGFuZ2UgdGhl DQoNCmVzc2VuY2Ugb2YgU1ItQkUgYW5kIGJlY29tZSB0aGUgU1ItVEUuDQozKSBMZWF2ZSBhcyBp dCBpcy4gVGhhdCBpcywgdGhlc2UgaXNzdWVzIGFyZSBub3Qgc29sdmVkIGZvciBTUiBwYXRoLiBJ biBteSBvd24gb3BpbmlvbiwgMjAgeWVhcnMgYWdvLCBvbmx5DQoNCnNvbHZpbmcgdGhlIHJlYWNo YWJpbGl0eSBpc3N1ZXMgbWF5IGJlIGFjY2VwdGVkLiBCdXQgdG9kYXksIGFzIHRoZSBjb25jZXB0 IG9mIGNhcnJpZXItZ3JhZGUgSVAgbmV0d29yayBoYXMgYmVlbg0KDQp3aWRlbHkgYWNjZXB0ZWQg YW5kIHRoZXNlIGZlYXR1cmVzIG1lbnRpb25lZCBoYXMgYmVlbiBkZXBsb3llZCBpbiB0aGUgdHJh ZGl0aW9uYWwgTVBMUyBuZXR3b3JrLCBJIGRvbid0IHRoaW5rDQoNCnRoZXkgY2FuIGJlIHJlbW92 ZWQgZWFzaWx5Lg0KDQpJbiBvbmUgd29yZCwgdGhvdWdoIHNvbWUgYWR2YW50YWdlIGRyaXZlbiBm cm9tIHRoZSByZWFjaGJpbGl0eSBvZiBTUiBpcyBhcHBhcmVudCwgdGhlIGNvbXBsZXhpdHkgaW50 cm9jdWRlZCBieQ0KDQp0aGUgc3ludGhlc2l6ZWQgcmVxdWlyZW1lbnRzIGFyZSBub3QgcmVkdWNl ZC4gQW5kIGl0IG1heSBiZWNvbWUgbW9yZSBjb21wbGV4IGZvciBTUi4NCg0KDQoNCg0KDQoNCg0K DQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

 

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

 

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

 

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages are from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network. 

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered, it means SR does not reduce

the compexity. Instead it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

 

 

 

 

Regards,

Robin

 

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863nkgeml506mbxchi_-- From nobody Wed Jan 28 05:05:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFF51A701A; Wed, 28 Jan 2015 04:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 J6LmEm6n8dWC; Wed, 28 Jan 2015 04:54:48 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681AB1A6FF9; Wed, 28 Jan 2015 04:54:48 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so10368677igq.0; Wed, 28 Jan 2015 04:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U55L7z0pNx58nuVTIOPGTNJ4PM6zqFwvj0e5KmNzzBU=; b=cj+vynFAn4TL6ba/lACfDWSvFQEEFW3K80omEQM9wliX0fMK22VYTOY22YpIbzx2gX qYOPGQiaNCbDUeXRJ1RM+oP0xYbT1sdxn7MWHKm8jQi6vj0ssIXZcSHlp044GV6PKjUR KDyrboQZvt48xOW+5DI5TtXNlKmfhgZ7iXp7ynDG+DfZ2wTyWkIgjBHQkb5pBE8wmyJQ WE5taAG6oLWXz/fiaZT4cW5M7z9ncvLyEYKqm6IM9EC8tbnGJkFByauZSqLzFOXOpkAE mnxzdMa9kTrY2e5db0YAECJ8moASPH3fWscVipnXhVU36MXQacXReRbQOThYqz1X/Wt3 MGgg== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr3319775igb.17.1422449687546; Wed, 28 Jan 2015 04:54:47 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.157.69 with HTTP; Wed, 28 Jan 2015 04:54:47 -0800 (PST) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com> Date: Wed, 28 Jan 2015 13:54:47 +0100 X-Google-Sender-Auth: AGdXyhykkaTUsvqxr_YVEBjhuG4 Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=001a11c3a9505650a1050db5e059 Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 05:05:41 -0800 Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 12:54:51 -0000 --001a11c3a9505650a1050db5e059 Content-Type: text/plain; charset=UTF-8 Robin, Most if not of your observations circle around idea to use segment routing as MPLS label signalling mechanism. I do not think this is that interesting scenario. Personally I would not deploy it for such purpose of hop by hop MPLS switching. We have LDP for that. Contrary I would use SR for controlled packet steering where responsibility is take to make the right header (be it label or extension headers) upon operator or his controller. To the point of the loop .. note that you may have valid cases to traverse given appliance (SFC use case) more then onces hence I would claim it is not aa architecture spec problem, but if so deployment bug. Best, r. On Wed, Jan 28, 2015 at 12:30 PM, Lizhenbin wrote: > Hi all authors of segment routing, > > > > This is the eighth comments. The issues proposed here apply to both SR-TE > path and SR-BE path. > > > > For LDP and RSVP-TE, there is the loop prevention mechanism when setup > LSP. For the SR, the SR path is always > > setup at the ingress node. It is difficult to detect the possible loop in > the network. For example, if the > > microloop of route happens, the loop prevention mechanism will prevent LDP > to setup LSP. But for the segment > > routing, once the ingress node downloads the forwarding entry and the > traffic will experience the microloop. > > How can SR to cope with the issue or just leave it as the traditional > routing? > > > > For LDP and RSVP-TE, there is the error notification mechanism based on > the LDP notification message or the > > RSVP-TE PathErr/Resv messages. Based on the error notification, the nodes > along the LSP can take possible > > actions against the possible errors. But for SR, there is no such > information communicated among the nodes > > along the SR Path. The result will be that once the packet is forwarded by > the ingress node, they may > > experience the possible errors which may be prevented by the negotiation > in the control plane. > > > > From the previous comments, we can see that in the traditional LSP, the > LSP setup is negotiated through > > the signalling between the upstream node and the downstream node. During > the negotiation, it is not only to > > set up the forwarding the entry for the purpose of reachablity, but also > includes many aspects (I call them > > as the operation and maintenence of the LSP. Hope it is appropriate. ) > such as the end-to-end connectivity > > verification, the loop prevention, path MTU, negotiation, path recording, > error notification and handling, > > etc. Though SR always proposes its advantage, in my opinion, these > advantages are from the reachability > > part such as the advantage that the label statck in the ingress node > reduces the states in the network. > > But the requirements of the operational and maintenance for the > traditional LSP still exist. Taking into > > account that the flooding mode of the IGP, it stops the communication > between the nodes along the path, > > the work may become more complex. According to the past experience, the > possible ways I could think out are > > as follows: > 1) Depend on the third-party mechanisms. But the problem is that there may > involve more mechanisms and there > > may be no mechanisms. For example, LSP Ping can be adopted to check the > end-to-end connectivity or loop for > > the SR-BE path, but it cannot be used for path MTU negotiation. For the > end-to-end path recording, LSP Tracert > > may have to be introduced. If these requirements and mechanisms are > considered, it means SR does not reduce > > the compexity. Instead it just transfers more complexity to the other > possible signallings. > 2) Depend on one nodes to implement the possible functions. For example, > for SR-TE path, it can depend on the > > PCE or the ingress node to collect all path info proposed by path > recording or even path MTU negotiation. Even so, > > there is still some drawbacks for some scenarios if only depend on the > ingress node. Moreover these methods > cannot apply to SR-BE path.If the possible work is done through the > ingress node, it will begin to change the > > essence of SR-BE and become the SR-TE. > 3) Leave as it is. That is, these issues are not solved for SR path. In my > own opinion, 20 years ago, only > > solving the reachability issues may be accepted. But today, as the concept > of carrier-grade IP network has been > > widely accepted and these features mentioned has been deployed in the > traditional MPLS network, I don't think > > they can be removed easily. > > In one word, though some advantage driven from the reachbility of SR is > apparent, the complexity introcuded by > > the synthesized requirements are not reduced. And it may become more > complex for SR. > > > > > > > > > > Regards, > > Robin > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a11c3a9505650a1050db5e059 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robin,

Most if not of your observations circle around idea to use segment ro= uting as MPLS label signalling mechanism. I do not think this is that inter= esting scenario. Personally I would not deploy it for such purpose of hop b= y hop MPLS switching. We have LDP for that.

Contrary I would use SR for controlled packet steering where re= sponsibility is take to make the right header (be it label or extension hea= ders) upon operator or his controller.=C2=A0

<= div class=3D"gmail_default" style=3D"font-family:courier new,monospace;font= -size:small">To the point of the loop .. note that you may have valid cases= to traverse given appliance (SFC use case) more then onces hence I would c= laim it is not aa architecture spec problem, but if so deployment bug.

Best,
r.

=C2=A0

On Wed, Jan 28, 2015 at 12:30 PM, Lizhe= nbin <lizhenbin@huawei.com> wrote:

Hi all authors of segment routing,

=C2=A0

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

=C2=A0

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

=C2=A0

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among=C2=A0the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

=C2=A0

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages=C2=A0are=C2=A0from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network.=C2=A0

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out=C2=A0are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered,=C2=A0it means SR does not reduce

the compexity. Instead=C2=A0it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Regards,

Robin

=C2=A0

=C2=A0


_______________________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring


--001a11c3a9505650a1050db5e059-- From nobody Wed Jan 28 07:24:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D731A0104; Wed, 28 Jan 2015 07:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OJCGCAjT0i5W; Wed, 28 Jan 2015 07:24:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3731A00DB; Wed, 28 Jan 2015 07:24:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128152429.28459.48847.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 07:24:29 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-te-express-path-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 15:24:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions Authors : Alia Atlas John Drake Spencer Giacalone Dave Ward Stefano Previdi Clarence Filsfils Filename : draft-ietf-teas-te-express-path-00.txt Pages : 10 Date : 2015-01-28 Abstract: In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification uses network performance data, such as is advertised via the OSPF and ISIS TE metric extensions (defined outside the scope of this document) to perform such path selections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-te-express-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-te-express-path-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 28 08:59:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C66C1A870D for ; Wed, 28 Jan 2015 08:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 he82b1mPA2_x for ; Wed, 28 Jan 2015 08:59:16 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F811A86F0 for ; Wed, 28 Jan 2015 08:59:16 -0800 (PST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t0SGKiK3010050 for ; Wed, 28 Jan 2015 08:59:15 -0800 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1s6f562h3w-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 28 Jan 2015 08:59:15 -0800 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 28 Jan 2015 09:59:14 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 28 Jan 2015 09:59:14 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Wed, 28 Jan 2015 09:59:13 -0700 From: Raqib Jones To: "teas@ietf.org" Thread-Topic: RSVP Hello location in rsvp te yang model Thread-Index: AdA7G7gnZheC+RBLTPqA4TAv0aBJWw== Date: Wed, 28 Jan 2015 16:59:13 +0000 Message-ID: <7759ef0e1dcb4b7186389bc209fe096f@BRMWP-EXMB11.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.72.36.5] Content-Type: multipart/alternative; boundary="_000_7759ef0e1dcb4b7186389bc209fe096fBRMWPEXMB11corpbrocadec_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-28_02:2015-01-28,2015-01-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501280164 Archived-At: Subject: [Teas] RSVP Hello location in rsvp te yang model X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 16:59:17 -0000 --_000_7759ef0e1dcb4b7186389bc209fe096fBRMWPEXMB11corpbrocadec_ Content-Type: text/plain; charset="us-ascii" Question on : https://github.com/ietf-mpls-yang/te/blob/master/ietf-rsvp-te.yang Can the Hello Parameters be separated from the GR container; as RSVP Hello may be run even when GR is not enabled? thanks, Raqib --_000_7759ef0e1dcb4b7186389bc209fe096fBRMWPEXMB11corpbrocadec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Question on :

 

https://github.com/ietf-mpls-yang/te/blob/master= /ietf-rsvp-te.yang

 

Can the Hello Parameters be separated from the GR co= ntainer;

as RSVP Hello may be run even when GR is not enabled= ?

 

thanks,

Raqib

--_000_7759ef0e1dcb4b7186389bc209fe096fBRMWPEXMB11corpbrocadec_-- From nobody Wed Jan 28 10:28:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003B1A1B06 for ; Wed, 28 Jan 2015 10:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 4Rcyvui8zbzz for ; Wed, 28 Jan 2015 10:28:52 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444ED1A1AE5 for ; Wed, 28 Jan 2015 10:28:52 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id k15so17403194qaq.9 for ; Wed, 28 Jan 2015 10:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uVsTQwqI3FCbMKR/OvQxegNDGq36p8yYC350ftDWJdQ=; b=crHkzG/y/CGVw62JVEi08GprYsIYm1vTPq70MAuqDpwIqNAsI/WkUQa3aJ6orld/75 hvV6l1WK8TDMS3ooz47WEiZOIQsESgYn2Pexq0SA/un6MnnaTnNcEUTkT3eIMYTNwdmG QwF62V7dhEi+lT7EZ/n3KuB0b/LG3Cf71+XcAr8QEoRCXVBxXTWn7hWBJD6iKex4Z5QR W0Iky6MlYma8voV1G6hfdltipZktaY4jfVeBx94RkDRpy7nse0XabycWqCT9HjBcWYvL BAC7QY6BgBKOAsCJblIM8trhUYRohr3T9WSbxiindFZmFJ0+eQyZckPE9AlXCANeSq// bWgw== MIME-Version: 1.0 X-Received: by 10.224.15.193 with SMTP id l1mr16071533qaa.2.1422469731474; Wed, 28 Jan 2015 10:28:51 -0800 (PST) Received: by 10.140.85.227 with HTTP; Wed, 28 Jan 2015 10:28:51 -0800 (PST) In-Reply-To: <7759ef0e1dcb4b7186389bc209fe096f@BRMWP-EXMB11.corp.brocade.com> References: <7759ef0e1dcb4b7186389bc209fe096f@BRMWP-EXMB11.corp.brocade.com> Date: Wed, 28 Jan 2015 13:28:51 -0500 Message-ID: From: Vishnu Pavan Beeram To: Raqib Jones Content-Type: multipart/alternative; boundary=047d7bea3e600c6414050dba8b94 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP Hello location in rsvp te yang model X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:28:54 -0000 --047d7bea3e600c6414050dba8b94 Content-Type: text/plain; charset=UTF-8 Agree. This was one of the things that we agreed to change in the last meeting. The next version will have the change. Regards, -Pavan On Wed, Jan 28, 2015 at 11:59 AM, Raqib Jones wrote: > Question on : > > > > https://github.com/ietf-mpls-yang/te/blob/master/ietf-rsvp-te.yang > > > > Can the Hello Parameters be separated from the GR container; > > as RSVP Hello may be run even when GR is not enabled? > > > > thanks, > > Raqib > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --047d7bea3e600c6414050dba8b94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree.
This was one of the things that we agreed = to change in the last meeting. The next version will have the change.
Regards,
-Pavan
<= br>
On Wed, Jan 28, 2015 at 11:59 AM, Raqib Jones= <raqib@brocade.com> wrote:

Question on :

=C2=A0

https://github.com/ietf-mpls-y= ang/te/blob/master/ietf-rsvp-te.yang

=C2=A0

Can the Hello Parameters be separated from the GR co= ntainer;

as RSVP Hello may be run even when GR is not enabled= ?

=C2=A0

thanks,

Raqib


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--047d7bea3e600c6414050dba8b94-- From nobody Wed Jan 28 14:22:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134191A0358; Wed, 28 Jan 2015 14:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 Eh_amq2nspIq; Wed, 28 Jan 2015 14:22:40 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1682C1A00D4; Wed, 28 Jan 2015 14:22:39 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0SMMX0K023933; Wed, 28 Jan 2015 22:22:33 GMT Received: from 950129200 (62-46-81-125.adsl.highway.telekom.at [62.46.81.125]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0SMMVsC023923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 22:22:32 GMT From: "Adrian Farrel" To: "'Lou Berger'" , "'Rakesh Gandhi \(rgandhi\)'" , References: <54C79ADB.3090009@labn.net> In-Reply-To: <54C79ADB.3090009@labn.net> Date: Wed, 28 Jan 2015 22:22:31 -0000 Message-ID: <08da01d03b48$e9219280$bb64b780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9k63ie6NiALRXyzCvf+If3BfdFgMDBnsKnWNR5AA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21290.002 X-TM-AS-Result: No--0.543-10.0-31-10 X-imss-scan-details: No--0.543-10.0-31-10 X-TMASE-MatchedRID: lORh06tOiKg4HKI/yaqRm5F+9R8v7nzms+SyIdviDny67Q3uPo9KI0dC bIqupRRAWcrhFCwikTD4ZVqLH9zJt29PyFCtLnnLbMGKOuLn5FV9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62ShEiggFNWnaRACvwCxQeWB5Y6ymVqv+liwXuSbUpmhsKyQJ T0cyLNAwkCnkA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrnqg/VrSZEiM= Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , teas@ietf.org Subject: Re: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 22:22:42 -0000 > Let's take a stab (off line) at language that addresses Adrian's > comment and captures (our understanding) of the intent of the existing > language, and then pass it around for review by all. If you can take a > stab at it and send it to me that would be best. That sounds like a fine idea because Rakesh's latest email sounds like "the reverse path LSP MUST NOT follow the same path as the forward path LSP" and I am sure that you don't want to say that! A From nobody Wed Jan 28 15:27:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B1A1A6F0B; Wed, 28 Jan 2015 15:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 MR_RyiFBj8l8; Wed, 28 Jan 2015 15:27:02 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A6A1A6F05; Wed, 28 Jan 2015 15:27:02 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-3b-54c9112ce250 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.AB.25146.C2119C45; Wed, 28 Jan 2015 17:41:17 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 18:27:00 -0500 From: Gregory Mirsky To: Lizhenbin , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AQHQOupzE7zeG6qIGUSmi4k6SnvYQZzWLOLQ Date: Wed, 28 Jan 2015 23:26:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonRFdX8GSIQUsXu0X/vSdsFrsb/7Bb 3Fq6ktXi+IXfjBatP3awOLB6tBx5y+qxZMlPJo/rTVfZA5ijuGxSUnMyy1KL9O0SuDK+37zC UnDqGGPFlynz2RoYVxxk7GLk5JAQMJH41baaHcIWk7hwbz1bFyMXh5DAEUaJIw8mMUE4yxkl Pi+ZzgRSxSZgJPFiYw9Yh4iAp8Sbe7NYQWxmgWyJry8usIHYwgKBEse/LAaq4QCqCZJY/lgB otxI4tzx84wgYRYBVYmVHSUgYV4BX4ltj4+zQKw6zyjx4X8PK0gNp0CYxLRZoSA1jEC3fT+1 hglik7jErSfzmSBuFpBYsuc8M4QtKvHy8T9WCFtRYl//dHaI+nyJxdNvMkHsEpQ4OfMJywRG 0VlIRs1CUjYLSdksoCuYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypGjtLi1LLcdCPD TYzA6Dsmwea4g3HBJ8tDjAIcjEo8vAYPjocIsSaWFVfmHmKU5mBREuctu3IwREggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANjS48p+7nvhxf9OTa7ymbb3YTURe8qE5r+PFpd+ddUcCXP0U0H XC7Ufm3pFfrZ9/r7t7ksF/8wlczr+lwrFOJ2QiHmRfj9dpZZ09c8FWnXnR6bIW//f27OV1v9 naZPOQTz+fjnVJzVnrNyW4dv7jIbgzsbTjt9WLUklqNmx6HLCYxLjpzb4HnlrxJLcUaioRZz UXEiAGEejwqfAgAA Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:27:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iaW4sIGV0LiBhbCwNCnBhcmRvbiBteSBuYcOvdmUgcXVlc3Rpb24gV2h5IFBhdGggTVRV IERpc2NvdmVyeSBpcyBub3Qgc3VmZmljaWVudD8gSSB0aGluayB0aGF0IHdpdGggU2VnbWVudCBS b3V0aW5nIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnN0cnVjdCB0aGUgTVRVIFNpemUgbWF0 cml4IG9mIHRoZSBwYXJ0aWN1bGFyIGRvbWFpbi4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogVGVhcyBbbWFp bHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhlbmJpbg0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU0NClRvOiBIYW5uZXMgR3JlZGxlcg0K Q2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0KU3ViamVj dDogW1RlYXNdIOetlOWkjTogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGlu Zyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNSDQoNCg0KSGkgSGFubmVzLA0KDQpJIGhhdmUgZXZl ciB0aG91Z2h0IGFib3V0IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgYmFzZWQgb24gdGhlIGZsb29k ZWQgTVRVIGluZm9ybWF0aW9uIHRocm91Z2ggSUdQLg0KDQpUaGVyZSBhcmUgc3RpbGwgdHdvIHBv c3NpYmxlIGlzc3VlczoNCg0KMS4gSW50ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ug bm90IG9ubHkgaW50cm9kdWNlIHRoZSBJR1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRl bnNpb25zLg0KDQoyLiBGb3IgU1ItQkUgcGF0aCwgaXQgaGFzIHRvIGludHJvZHVjZSB0aGUgVEUt bGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRpb24gYXQgdGhlIGluZ3Jlc3Mgbm9kZS4NCg0K DQoNCk15IGNvbmNlcm4gaXMgbm90IGp1c3QgZm9yIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMsIGJ1 dCB0byBleHBsb3JlIHRoZSBlc3NlbmNlIG9mIFNSIHdoaWNoIG1heSBoYXMgbXVjaA0KDQplZmZl Y3Qgb24gaXRzIGRlcGxveW1lbnQgY29tcGFyaW5nIHdpdGggdGhlIGV4aXN0aW5nIE1QTFMgcHJv dG9jb2wuIEl0IHdpbGwgYmUgZXhwbGFpbmVkIGluDQoNCnRoZSBuZXh0IGNvbW1lbnRzLg0KDQoN Cg0KDQoNClJlZ2FyZHMsDQoNClJvYmluDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6OiBIYW5uZXMgR3JlZGxlciBbaGFu bmVzQGp1bmlwZXIubmV0XQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDI45pelIDQ6MDENCuaU tuS7tuS6ujogTGl6aGVuYmluDQrmioTpgIE6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHRlYXNAaWV0 Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbc3ByaW5nXSBOZXcgQ29t bWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25s eSBjYW4gc3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUg dXMgYSB3YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdl IGNvdWxkIGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQg aW1wbGVtZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3Mu DQoNCi9oYW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwg TGl6aGVuYmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcs DQp8DQp8ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0K fA0KfA0KfCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAg ICAgMQ0KfCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0t LS0tLS0tLVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAg ICAgICAgMXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0t LS0tLVMyMy0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAg ICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtl IHRoZSB0b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIg dGhlDQp8ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBs aWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAg aW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxh YmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRo IGFyZSBkaWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0 aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwg YnV0IG1heSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBw YXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2Yg dGhlDQp8DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0 aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBj YW4gZGVkdWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0K fCAgICB3aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25l IFNSIHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAg IFNSLVRFIHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6 YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lk ZXMgYWJvdmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8g dHJhY2sgdGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRo cm91Z2ggc2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFk b3B0ZWQgaW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRF IHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlz IG5vDQp8ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlv bi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sN CnwgICAgdGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2Rl cyBhbG9uZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0K fCAgICBSb2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQo= --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7 DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2lt U3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D Tjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgUm9iaW4sIGV0LiBhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+cGFyZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5v dCBzdWZmaWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQg YmUgcG9zc2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXggb2YNCiB0aGUgcGFy dGljdWxhciBkb21haW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MaXpoZW5iaW48YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBH cmVkbGVyPGJyPg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRl YXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIDwvc3Bhbj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuetlOWkjTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0 aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+SGkgSGFubmVzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+SSBoYXZlIGV2 ZXIgdGhvdWdodCBhYm91dCB0aGUgcG9zc2libGUgc29sdXRpb25zIGJhc2VkIG9uIHRoZSBmbG9v ZGVkIE1UVSBpbmZvcm1hdGlvbiB0aHJvdWdoIElHUC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlRo ZXJlIGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ MS4gSW50ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNl IHRoZSBJR1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtj b2xvcjpibGFjayI+Mi4gRm9yIFNSLUJFIHBhdGgsIGl0IGhhcyB0byBpbnRyb2R1Y2UgdGhlIFRF LWxpa2UgZW5kLXRvLWVuZCBwYXRoIGNhbGN1bGF0aW9uIGF0IHRoZSBpbmdyZXNzIG5vZGUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+TXkgY29uY2VybiBpcyBub3QganVz dCBmb3IgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ug b2YgU1INCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFj ayI+d2hpY2ggbWF5IGhhcyBtdWNoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ZWZmZWN0IG9uIGl0cyBkZXBsb3ltZW50IGNvbXBh cmluZyB3aXRoIHRoZSBleGlzdGluZyBNUExTIHByb3RvY29sLiBJdCB3aWxsIGJlIGV4cGxhaW5l ZCBpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29s b3I6YmxhY2siPnRoZSBuZXh0IGNvbW1lbnRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xv cjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5Sb2Jpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OmJsYWNrIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjogSGFubmVzIEdyZWRsZXIgW2hh bm5lc0BqdW5pcGVyLm5ldF08YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+OiAy MDE1PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjE8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Mjg8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7m l6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+DQogNDowMTxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj46 IExpemhlbmJpbjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPuaKhOmAgTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+DQptcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBD aGFsbGVuZ2VzIGZvciBTUjxicj4NCjxicj4NCm9ubHkgY2FuIHNwZWFrIGZvciBJUy1JUyAtPGJy Pg0KYWZhaWsgdGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcg dGhlIE1UVSBvZiBhIGxpbmsgLi4uPGJyPg0KPGJyPg0Kc28gd2hhdCB3ZSBjb3VsZCBkbyBpcyB0 byBhZHZlcnRpc2UgdGhlIE1UVSBmb3IgZWFjaCBhZGphY2VuY3kgYW5kIGltcGxlbWVudDxicj4N CnByb3BlciBmcmFnbWVudGF0aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy48YnI+DQo8YnI+ DQovaGFubmVzPGJyPg0KPGJyPg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSAm IzQzOzAwMDAsIExpemhlbmJpbiB3cm90ZTo8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIGFs bCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGluZyw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyBUaGlzIGlzIHRoZSBzZXZlbnRoIGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVy ZSBhcmUgZm9yIGJvdGggU1ItVEU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggYW5kIFNS LUJFIHBhdGguPGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxPGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTMTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1T MTQtLS0tLS0tLS1TMTU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMXw8YnI+DQp8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUzIxLS0tLS0t LS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1PGJyPg0KfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0PGJyPg0K fDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBTdGlsbCB0YWtlIHRoZSB0 b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlPGJy Pg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBsb29zZSBleHBsaWNpdCBwYXRoIG9yPGJyPg0KfDxicj4N CnwmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9v c2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu dGVyZmFjZSBpcyB0aGUgc2FtZSw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBzaW5j ZSB0aGUgZGVwdGggb2YgdGhlIGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQg dGhlIGJhY2t1cDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgcGF0aCBhcmUgZGlmZmVyZW50Ljxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhl IGVmZmV0aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlPGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyBwcmltYXJ5IHBhdGgsIGJ1dCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgbGFiZWwg c3RhY2tzIG9mIHRoZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW1hcnkgcGF0 aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLjxi cj4NCnw8YnI+DQp8PGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbSB0aGUgY2Fz ZSwgd2UgY2FuIGRlZHVjZSB0aGF0IHRoZSByaXNrIG1heSBleGlzdHMgZm9yIGFueSBzY2VuYXJp b3MgaW48YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWM8YnI+ DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXkgc3dpdGNoIGZyb20gb25lIFNS IHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzPGJyPg0KfCZu YnNwOyZuYnNwOyZuYnNwOyBTUi1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURTxicj4NCnw8YnI+DQp8 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24gYW5kIFNSLUJFIHBh dGggc3VjaCBhcyBUSS1GUlIuPGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNw OyZuYnNwOyBCZXNpZGVzIGFib3ZlIGlzc3VlcywgTERQL1JTVlAtVEUgY2FuIHN1cHBvcnQgdGhl IHBhdGggTVRVIHRvIHRyYWNrIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgTVRVIGluZm9y bWFpdG9uIGFsb25nIHRoZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExTUCB0aHJv dWdoIHNpZ25hbGxpbmcuIFRoZW4gdGhlIHJlYXNvbmFibGUgTVRVIGluZm8gd2lsbCBiZSBhZG9w dGVkIGluPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90 aDxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSLVRFIHBhdGggKGlmIFBD RSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vPGJyPg0KfCZu YnNwOyZuYnNwOyZuYnNwOyBzaWduYWxsaW5nIHRvIGFkdmVydGlzZTxicj4NCnw8YnI+DQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBpbmZvcm1hdGlvbi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVh dHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2s8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo YXQgdGhlIHBhY2tldCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBkcm9w cGVkIGJ5IHRoZSBub2RlcyBhbG9uZyB0aGUgTFNQLjxicj4NCnw8YnI+DQp8PGJyPg0KfDxicj4N Cnw8YnI+DQp8PGJyPg0KfDxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMs PGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgUm9iaW48YnI+DQo8YnI+DQp8IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KfCBzcHJpbmcg bWFpbGluZyBsaXN0PGJyPg0KfCA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PGJyPg0KfCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7347100B5761DC41A166AC17F22DF1121B8E9553eusaamb103erics_-- From nobody Wed Jan 28 22:46:56 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874111A8F39; Wed, 28 Jan 2015 22:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zX8uMARLtzhi; Wed, 28 Jan 2015 22:46:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D402F1A8F34; Wed, 28 Jan 2015 22:46:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON78927; Thu, 29 Jan 2015 06:46:38 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 06:46:25 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 14:46:19 +0800 From: Lizhenbin To: Gregory Mirsky , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIEACVSxAAAf89Kl Date: Thu, 29 Jan 2015 06:46:18 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAAC@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8E9553@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [Teas] =?utf-8?b?562U5aSNOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2Vn?= =?utf-8?q?ment_Routing=287=29=3A_MTU_Challenges_for_SR?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 06:46:45 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KUGxlYXNlIHJlZmVyIHRvIG15IGlubGluZSBjb21tZW50cy4NCg0KDQoNClJl Z2FyZHMsDQoNClJvYmluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 5Y+R5Lu25Lq6OiBHcmVnb3J5IE1pcnNreSBbZ3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tXQ0K 5Y+R6YCB5pe26Ze0OiAyMDE15bm0MeaciDI55pelIDc6MjYNCuaUtuS7tuS6ujogTGl6aGVuYmlu OyBIYW5uZXMgR3JlZGxlcg0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7 IHRlYXNAaWV0Zi5vcmcNCuS4u+mimDogUkU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdt ZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpIaSBSb2JpbiwgZXQuIGFs LA0KcGFyZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5v dCBzdWZmaWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQg YmUgcG9zc2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXggb2YgdGhlIHBhcnRp Y3VsYXIgZG9tYWluLg0KW1JvYmluXSBNeSBvcGluaW9uIGlzIHRoYXQgdGhlIHRoZXJlIGlzIGxp bWl0YXRpb24gZm9yIHRoZSBwYXRoIE1UVSBkaXNjb3ZlcnkgYmFzZWQgb24gSUdQLiAgRm9yIHRo ZSBpbnRlci1hcmVhIGFuZCBTUi1CRSBwYXRoIHNjZW5hcmlvcywgdGhlcmVzdGlsbCAgbmVlZCBl eHRyYSBtZWNoYW5pc21zLiBGb3IgdGhlIGZpcnN0IHNjZW5hcmlvLCBpdCB3aWxsIGluY3JlYXNl IHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzb2x1dGlvbnMuIEZvciB0aGUgc2Vjb25kIHNjZW5hcmlv LCBpdCBtYXkgaHVydCBmYXN0IGNvbnZlcmdlbmNlIG9mIGJlc3QtZWZmb3J0IHBhdGguDQoNCg0K DQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZw0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTGl6aGVuYmluDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMzow NiBBTQ0KVG86IEhhbm5lcyBHcmVkbGVyDQpDYzogbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYu b3JnOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10g562U5aSNOiBbc3ByaW5nXSBOZXcg Q29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0K DQpIaSBIYW5uZXMsDQoNCkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNv bHV0aW9ucyBiYXNlZCBvbiB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1Au DQoNClRoZXJlIGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVh IGZvciBTUi1URSBwYXRoOiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRl bnNpb25zLCBidXQgYWxzbyBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBp dCBoYXMgdG8gaW50cm9kdWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlv biBhdCB0aGUgaW5ncmVzcyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3Ig dGhlIHBvc3NpYmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Ig d2hpY2ggbWF5IGhhcyBtdWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcg d2l0aCB0aGUgZXhpc3RpbmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4N Cg0KdGhlIG5leHQgY29tbWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoN Cg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hk u7bkuro6IEhhbm5lcyBHcmVkbGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQrlj5HpgIHml7bpl7Q6 IDIwMTXlubQx5pyIMjjml6UgNDowMQ0K5pS25Lu25Lq6OiBMaXpoZW5iaW4NCuaKhOmAgTogc3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPjsgdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCuS4 u+mimDogUmU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1U VSBDaGFsbGVuZ2VzIGZvciBTUg0KDQpvbmx5IGNhbiBzcGVhayBmb3IgSVMtSVMgLQ0KYWZhaWsg dGhlIFRyaWxsIGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBv ZiBhIGxpbmsgLi4uDQoNCnNvIHdoYXQgd2UgY291bGQgZG8gaXMgdG8gYWR2ZXJ0aXNlIHRoZSBN VFUgZm9yIGVhY2ggYWRqYWNlbmN5IGFuZCBpbXBsZW1lbnQNCnByb3BlciBmcmFnbWVudGF0aW9u IGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy4NCg0KL2hhbm5lcw0KDQpPbiBUdWUsIEphbiAyNywg MjAxNSBhdCAxMToyNDoyM0FNICswMDAwLCBMaXpoZW5iaW4gd3JvdGU6DQp8ICAgIEhpIGFsbCBh dXRob3JzIG9mIHNlZ21lbnQgcm91dGluZywNCnwNCnwgICAgVGhpcyBpcyB0aGUgc2V2ZW50aCBj b21tZW5zLiBUaGUgaXNzdWVzIHByb3Bvc2VkIGhlcmUgYXJlIGZvciBib3RoIFNSLVRFDQp8ICAg IHBhdGggYW5kIFNSLUJFIHBhdGguDQp8DQp8DQp8DQp8ICAgICAgICAgICAgIDEgICAgICAgICAg ICAgIDEgICAgICAgICAgIDEgICAgICAgICAgICAxDQp8ICAgICAgUzExLS0tLS0tLS0tLS1TMTIt LS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0LS0tLS0tLS0tUzE1DQp8ICAgICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCnwgICAgICAxfCAgICAg ICAgICAgIDF8ICAgICAgICAgICAxfCAgICAgICAgICAxfCAgICAgICAgICAxfA0KfCAgICAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICB8DQp8ICAg ICAgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0tUzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1 DQp8ICAgICAgICAgICAgIDQgICAgICAgICAgICAgIDQgICAgICAgICAgIDQgICAgICAgICAgICA0 DQp8DQp8DQp8DQp8ICAgIFN0aWxsIHRha2UgdGhlIHRvcG9sb2d5IGluIHRoZSBjb21tZW50IDYg YXMgdGhlIGV4YW1wbGUuIE5vIG1hdHRlciB0aGUNCnwgICAgbG9vc2UgZXhwbGljaXQgcGF0aCBv cg0KfA0KfCAgICB0aGUgc3RyaWN0IGV4cGxpY2l0IHBhdGggZm9yIHRoZSBsb29zZSBob3AsIGFz c3VtZSB0aGUgTVRVIG9mIHRoZQ0KfCAgICBpbnRlcmZhY2UgaXMgdGhlIHNhbWUsDQp8DQp8ICAg IHNpbmNlIHRoZSBkZXB0aCBvZiB0aGUgbGFiZWwgc3RhY2tzIGZvciB0aGUgcHJpbWFyeSBwYXRo IGFuZCB0aGUgYmFja3VwDQp8ICAgIHBhdGggYXJlIGRpZmZlcmVudC4NCnwNCnwgICAgVGhlcmUg aXMgdGhlIHJpc2sgdGhhdCB0aGUgZWZmZXRpdmUgcGF5bG9hZCBtYXkgdHJhbnNtaXQgdGhyb3Vn aCB0aGUNCnwgICAgcHJpbWFyeSBwYXRoLCBidXQgbWF5IGJlDQp8DQp8ICAgIGZyYWdtZW50ZWQg b3IgZHJvcHBlZCBpbiB0aGUgYmFja3VwIHBhdGguIEFzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g dGhlDQp8ICAgIGxhYmVsIHN0YWNrcyBvZiB0aGUNCnwNCnwgICAgcHJpbWFyeSBwYXRoIGFuZCB0 aGUgYmFja3VwIHBhdGggaW5jcmVhc2UsIHRoZSByaXNrIHdpbGwgaW5jcmVhc2UuDQp8DQp8DQp8 DQp8ICAgIEZyb20gdGhlIGNhc2UsIHdlIGNhbiBkZWR1Y2UgdGhhdCB0aGUgcmlzayBtYXkgZXhp c3RzIGZvciBhbnkgc2NlbmFyaW9zIGluDQp8ICAgIHdoaWNoIHRoZSBzYW1lIHRyYWZmaWMNCnwN CnwgICAgIG1heSBzd2l0Y2ggZnJvbSBvbmUgU1IgcGF0aCB0byB0aGUgb3RoZXIgU1IgcGF0aC4g VGhlIFNSIHBhdGggaW5jbHVkZXMNCnwgICAgU1ItVEUgcGF0aCBzdWNoIGFzIE1QTFMgVEUNCnwN CnwgICAgaG90c3RhbmRieS9yZW9wdGltaXphdGlvbiBhbmQgU1ItQkUgcGF0aCBzdWNoIGFzIFRJ LUZSUi4NCnwNCnwNCnwNCnwgICAgQmVzaWRlcyBhYm92ZSBpc3N1ZXMsIExEUC9SU1ZQLVRFIGNh biBzdXBwb3J0IHRoZSBwYXRoIE1UVSB0byB0cmFjayB0aGUNCnwgICAgTVRVIGluZm9ybWFpdG9u IGFsb25nIHRoZQ0KfA0KfCAgICBMU1AgdGhyb3VnaCBzaWduYWxsaW5nLiBUaGVuIHRoZSByZWFz b25hYmxlIE1UVSBpbmZvIHdpbGwgYmUgYWRvcHRlZCBpbg0KfCAgICB0aGUgaW5ncmVzcyBub2Rl LiBGb3IgYm90aA0KfA0KfCAgICAgU1ItVEUgcGF0aCAoaWYgUENFIGlzIG5vdCB1c2VkKSBhbmQg U1ItQkUgcGF0aCwgc2luY2UgdGhlcmUgaXMgbm8NCnwgICAgc2lnbmFsbGluZyB0byBhZHZlcnRp c2UNCnwNCnwgICAgdGhlIGluZm9ybWF0aW9uLiBIb3cgdG8gaW1wbGVtZW50IHRoZSBmZWF0dXJl PyBPciB0aGVyZSBtYXliZSB0aGUgcmlzaw0KfCAgICB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlDQp8 DQp8ICAgIGRyb3BwZWQgYnkgdGhlIG5vZGVzIGFsb25nIHRoZSBMU1AuDQp8DQp8DQp8DQp8DQp8 DQp8DQp8DQp8ICAgIFJlZ2FyZHMsDQp8DQp8ICAgIFJvYmluDQoNCnwgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnwgc3ByaW5nIG1haWxpbmcgbGlzdA0K fCBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCnwgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGU+QGZvbnQtZmFjZSB7 DQoJZm9udC1mYW1pbHk6IENvdXJpZXI7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTog U2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFNpbVN1bjsNCn0NCkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IFRhaG9tYTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7bWFyZ2luOiAxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjsgfQ0KUC5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZP TlQtRkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogMTJwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglN QVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6IDEycHQN Cn0NCkRJVi5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiBT aW1TdW47IEZPTlQtU0laRTogMTJwdA0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1 cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9s bG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpQ Lk1zb0FjZXRhdGUgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGFob21h Iiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogOHB0DQp9DQpMSS5Nc29BY2V0YXRlIHsNCglNQVJH SU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRhaG9tYSIsInNhbnMtc2VyaWYiOyBGT05U LVNJWkU6IDhwdA0KfQ0KRElWLk1zb0FjZXRhdGUgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZP TlQtRkFNSUxZOiAiVGFob21hIiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogOHB0DQp9DQpTUEFO LkVtYWlsU3R5bGUxOCB7DQoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENP TE9SOiAjMWY0OTdkDQp9DQpTUEFOLkJhbGxvb25UZXh0Q2hhciB7DQoJRk9OVC1GQU1JTFk6ICJU YWhvbWEiLCJzYW5zLXNlcmlmIg0KfQ0KLk1zb0NocERlZmF1bHQgew0KCUZPTlQtU0laRTogMTBw dA0KfQ0KPC9zdHlsZT48c3R5bGUgaWQ9Im93YVBhcmFTdHlsZSI+UCB7DQoJTUFSR0lOLVRPUDog MHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgZlBTdHlsZT0iMSIgb2NzaT0iMCI+ DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTogVGFob21hO2NvbG9yOiAj MDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPg0KPHA+SGkgR3JlZyw8L3A+DQo8cD5QbGVhc2UgcmVm ZXIgdG8gbXkgaW5saW5lIGNvbW1lbnRzLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPlJlZ2FyZHMs PC9wPg0KPHA+Um9iaW48L3A+DQo8cD4mbmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJGT05ULUZBTUlM WTogVGltZXMgTmV3IFJvbWFuOyBDT0xPUjogIzAwMDAwMDsgRk9OVC1TSVpFOiAxNnB4Ij4NCjxo ciB0YWJpbmRleD0iLTEiPg0KPGRpdiBzdHlsZT0iRElSRUNUSU9OOiBsdHIiIGlkPSJkaXZScEY4 ODg5ODUiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxiPuWP keS7tuS6ujo8L2I+IEdyZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21d PGJyPg0KPGI+5Y+R6YCB5pe26Ze0OjwvYj4gMjAxNeW5tDHmnIgyOeaXpSA3OjI2PGJyPg0KPGI+ 5pS25Lu25Lq6OjwvYj4gTGl6aGVuYmluOyBIYW5uZXMgR3JlZGxlcjxicj4NCjxiPuaKhOmAgTo8 L2I+IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZzxicj4NCjxi PuS4u+mimDo8L2I+IFJFOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2VnbWVudCBSb3V0aW5n KDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1I8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2 PjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7 IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkhpIFJvYmluLCBldC4gYWwsPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+cGFy ZG9uIG15IG5hw692ZSBxdWVzdGlvbiBXaHkgUGF0aCBNVFUgRGlzY292ZXJ5IGlzIG5vdCBzdWZm aWNpZW50PyBJIHRoaW5rIHRoYXQgd2l0aCBTZWdtZW50IFJvdXRpbmcgaXQgd291bGQgYmUgcG9z c2libGUgdG8gY29uc3RydWN0IHRoZSBNVFUgU2l6ZSBtYXRyaXgNCiBvZiB0aGUgcGFydGljdWxh ciBkb21haW4uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt U0laRTogMTFwdCI+W1JvYmluXSZuYnNwO015IG9waW5pb24mbmJzcDtpcyZuYnNwO3RoYXQmbmJz cDt0aGUgdGhlcmUgaXMgbGltaXRhdGlvbiBmb3IgdGhlIHBhdGggTVRVIGRpc2NvdmVyeSBiYXNl ZCBvbiBJR1AuJm5ic3A7IEZvciB0aGUgaW50ZXItYXJlYSBhbmQgU1ItQkUgcGF0aCBzY2VuYXJp b3MsIHRoZXJlc3RpbGwgJm5ic3A7bmVlZA0KIGV4dHJhIG1lY2hhbmlzbXMuIEZvciB0aGUgZmly c3Qgc2NlbmFyaW8sIGl0IHdpbGwgaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIHNvbHV0 aW9ucy4gRm9yIHRoZSBzZWNvbmQgc2NlbmFyaW8sIGl0IG1heSBodXJ0IGZhc3QgY29udmVyZ2Vu Y2Ugb2YgYmVzdC1lZmZvcnQgcGF0aC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0 Ij48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3Nw YW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAx MXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgR3JlZzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG T05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctVE9QOiAzcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn OyBGT05ULVNJWkU6IDEwcHQiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5MaXpoZW5iaW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBKYW51YXJ5IDI4LCAyMDE1IDM6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBHcmVkbGVy PGJyPg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRlYXNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RlYXNdIDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjogW3Nwcmlu Z10gTmV3IENvbW1lbnRzIG9uIFNlZ21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9y IFNSPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+SGkgSGFubmVzLDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDEwcHQiPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJp ZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij5JIGhhdmUgZXZlciB0aG91Z2h0IGFi b3V0IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMgYmFzZWQgb24gdGhlIGZsb29kZWQgTVRVIGluZm9y bWF0aW9uIHRocm91Z2ggSUdQLjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsg Rk9OVC1TSVpFOiAxMHB0Ij5UaGVyZSBhcmUgc3RpbGwgdHdvIHBvc3NpYmxlIGlzc3Vlczo8L3Nw YW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+MS4gSW50 ZXItYXJlYSBmb3IgU1ItVEUgcGF0aDogTWF5YmUgd2Ugbm90IG9ubHkgaW50cm9kdWNlIHRoZSBJ R1AgZXh0ZW5zaW9ucywgYnV0IGFsc28gUENFUCBleHRlbnNpb25zLjwvc3Bhbj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05U LVNJWkU6IDEwcHQiPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENv dXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4yLiBGb3IgU1ItQkUgcGF0aCwg aXQgaGFzIHRvIGludHJvZHVjZSB0aGUgVEUtbGlrZSBlbmQtdG8tZW5kIHBhdGggY2FsY3VsYXRp b24gYXQgdGhlIGluZ3Jlc3Mgbm9kZS48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn VGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0la RTogMTBwdCI+TXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3NpYmxlIHNvbHV0aW9u cywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1INCjwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjayI+d2hpY2ggbWF5IGhhcyBtdWNoPC9z cGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogQ291cmllcjsgQ09MT1I6IGJsYWNrIj5lZmZlY3Qgb24gaXRzIGRlcGxveW1l bnQgY29tcGFyaW5nIHdpdGggdGhlIGV4aXN0aW5nIE1QTFMgcHJvdG9jb2wuIEl0IHdpbGwgYmUg ZXhwbGFpbmVkIGluPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgQ09MT1I6IGJsYWNrIj50aGUgbmV4 dCBjb21tZW50cy48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1T SVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiBDb3VyaWVyOyBDT0xPUjogYmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTog MTBwdCI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsg Q09MT1I6IGJsYWNrIj5Sb2Jpbjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+ Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjog YmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+ OiBIYW5uZXMgR3JlZGxlciBbaGFubmVzQGp1bmlwZXIubmV0XTxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7lj5HpgIHm l7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxh Y2s7IEZPTlQtU0laRTogMTBwdCI+OiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxh Y2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4xPC9z cGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgt Q04iPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXI7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4yODwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiBDb3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+DQogNDow MTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQi IGxhbmc9IlpILUNOIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBD b3VyaWVyOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+OiBMaXpoZW5iaW48YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJa SC1DTiI+5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllcjsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjoNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9y ZzwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAx MHB0IiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog Q291cmllcjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjogUmU6IFtzcHJpbmddIE5l dyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBDaGFsbGVuZ2VzIGZvciBTUjxi cj4NCjxicj4NCm9ubHkgY2FuIHNwZWFrIGZvciBJUy1JUyAtPGJyPg0KYWZhaWsgdGhlIFRyaWxs IGV4dGVuc2lvbnMgZ2F2ZSB1cyBhIHdheSBvZiBzaWduYWxpbmcgdGhlIE1UVSBvZiBhIGxpbmsg Li4uPGJyPg0KPGJyPg0Kc28gd2hhdCB3ZSBjb3VsZCBkbyBpcyB0byBhZHZlcnRpc2UgdGhlIE1U VSBmb3IgZWFjaCBhZGphY2VuY3kgYW5kIGltcGxlbWVudDxicj4NCnByb3BlciBmcmFnbWVudGF0 aW9uIGF0IHRoZSBURSB0dW5uZWwgaW5ncmVzcy48YnI+DQo8YnI+DQovaGFubmVzPGJyPg0KPGJy Pg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSAmIzQzOzAwMDAsIExpemhlbmJp biB3cm90ZTo8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIGFsbCBhdXRob3JzIG9mIHNlZ21l bnQgcm91dGluZyw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIHRoZSBz ZXZlbnRoIGNvbW1lbnMuIFRoZSBpc3N1ZXMgcHJvcG9zZWQgaGVyZSBhcmUgZm9yIGJvdGggU1It VEU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggYW5kIFNSLUJFIHBhdGguPGJyPg0KfDxi cj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT MTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1TMTMtLS0tLS0tLS1TMTQtLS0tLS0tLS1TMTU8YnI+ DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMXw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxicj4NCnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUzIxLS0tLS0tLS0tLS1TMjItLS0tLS0tLS0t UzIzLS0tLS0tLS0tUzI0LS0tLS0tLS0tUzI1PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJy Pg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBTdGlsbCB0YWtlIHRoZSB0b3BvbG9neSBpbiB0aGUgY29t bWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlPGJyPg0KfCZuYnNwOyZuYnNwOyZu YnNwOyBsb29zZSBleHBsaWNpdCBwYXRoIG9yPGJyPg0KfDxicj4NCnwmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIHN0cmljdCBleHBsaWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhl IE1UVSBvZiB0aGU8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyZmFjZSBpcyB0aGUgc2Ft ZSw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBzaW5jZSB0aGUgZGVwdGggb2YgdGhl IGxhYmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cDxicj4NCnwm bmJzcDsmbmJzcDsmbmJzcDsgcGF0aCBhcmUgZGlmZmVyZW50Ljxicj4NCnw8YnI+DQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZlIHBheWxvYWQg bWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBwcmltYXJ5 IHBhdGgsIGJ1dCBtYXkgYmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBmcmFnbWVu dGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgbGFiZWwgc3RhY2tzIG9mIHRoZTxicj4N Cnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBw YXRoIGluY3JlYXNlLCB0aGUgcmlzayB3aWxsIGluY3JlYXNlLjxicj4NCnw8YnI+DQp8PGJyPg0K fDxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbSB0aGUgY2FzZSwgd2UgY2FuIGRlZHVjZSB0 aGF0IHRoZSByaXNrIG1heSBleGlzdHMgZm9yIGFueSBzY2VuYXJpb3MgaW48YnI+DQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHdoaWNoIHRoZSBzYW1lIHRyYWZmaWM8YnI+DQp8PGJyPg0KfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtYXkgc3dpdGNoIGZyb20gb25lIFNSIHBhdGggdG8gdGhlIG90aGVy IFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBT Ui1URSBwYXRoIHN1Y2ggYXMgTVBMUyBURTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIu PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBCZXNpZGVzIGFi b3ZlIGlzc3VlcywgTERQL1JTVlAtVEUgY2FuIHN1cHBvcnQgdGhlIHBhdGggTVRVIHRvIHRyYWNr IHRoZTxicj4NCnwmbmJzcDsmbmJzcDsmbmJzcDsgTVRVIGluZm9ybWFpdG9uIGFsb25nIHRoZTxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExTUCB0aHJvdWdoIHNpZ25hbGxpbmcuIFRo ZW4gdGhlIHJlYXNvbmFibGUgTVRVIGluZm8gd2lsbCBiZSBhZG9wdGVkIGluPGJyPg0KfCZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgaW5ncmVzcyBub2RlLiBGb3IgYm90aDxicj4NCnw8YnI+DQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNSLVRFIHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5k IFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vPGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBz aWduYWxsaW5nIHRvIGFkdmVydGlzZTxicj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBpbmZvcm1hdGlvbi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5 YmUgdGhlIHJpc2s8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIHBhY2tldCBtYXkg YmU8YnI+DQp8PGJyPg0KfCZuYnNwOyZuYnNwOyZuYnNwOyBkcm9wcGVkIGJ5IHRoZSBub2RlcyBh bG9uZyB0aGUgTFNQLjxicj4NCnw8YnI+DQp8PGJyPg0KfDxicj4NCnw8YnI+DQp8PGJyPg0KfDxi cj4NCnw8YnI+DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPGJyPg0KfDxicj4NCnwmbmJz cDsmbmJzcDsmbmJzcDsgUm9iaW48YnI+DQo8YnI+DQp8IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KfCBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0K fCA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjxicj4NCnwgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BAACnkgeml506mbxchi_-- From nobody Wed Jan 28 23:06:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D181A8AFA; Wed, 28 Jan 2015 23:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.133 X-Spam-Level: **** X-Spam-Status: No, score=4.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 fGp9pLkWnI0F; Wed, 28 Jan 2015 23:06:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78FB1A1B51; Wed, 28 Jan 2015 23:06:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW04070; Thu, 29 Jan 2015 07:06:35 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 07:06:34 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 15:06:29 +0800 From: Lizhenbin To: Uma Chunduri , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AdA6Iy10hnzSmHMYSNeVsID5YDgzbAABb2SAADAnQIEAEuyzAAAWqcJr Date: Thu, 29 Jan 2015 07:06:28 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACE@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com>, <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [Teas] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg3KTogTVRVIENoYWxsZW5nZXMgZm9yIFNS?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 07:06:40 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVW1hLA0KDQpQbGVhc2UgcmVmZXIgdG8gbXkgaW5saW5lIGNvbW1lbnRzLg0KDQoNCg0KUmVn YXJkcywNCg0KUm9iaW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IFVtYSBDaHVuZHVyaSBbdW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbV0NCreiy83Ksbzk OiAyMDE1xOox1MIyOcjVIDEyOjAxDQrK1bz+yMs6IExpemhlbmJpbjsgSGFubmVzIEdyZWRsZXIN CrOty806IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgdGVhc0BpZXRmLm9yZw0K1vfM 4jogUkU6IFtzcHJpbmddIE5ldyBDb21tZW50cyBvbiBTZWdtZW50IFJvdXRpbmcoNyk6IE1UVSBD aGFsbGVuZ2VzIGZvciBTUg0KDQpIaSBSb2JpbiwNCg0KSWYgd2UgaGF2ZSBNVFUgaXNzdWVzIHdp dGggaW4gYW4gYXJlYSwgSSBzZWUgdHJvdWJsZSBpbiBiYXNpYyBJR1AgZnVuY3Rpb25pbmcgKGZv ciBleGFtcGxlIGl0oa9zIGEgc2VyaW91cyBpc3N1ZSB3aXRoIElTLUlTIGZvciBiYXNpYyBvcGVy YXRpb24pLg0KW1JvYmluXSBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmUgZXhpc3RzIHRoZSBN VFUgaXNzdWUgZm9yIHRoZSByb3V0aW5nIGZ1bmN0aW9uaW5nLiBCdXQgdGhlIE1UVSBpc3N1ZSBj YW4gYmUgc29sdmVkIGJ5IHRoZSBwYXRoIE1UVSBtZWNoYW5pc20gcHJvdmlkZWQgYnkgTERQL1JT VlAtVEUuIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgU1IgcGF0aCBiYXNlZCBvbiB0aGUgTVBMUyBm b3J3YXJkaW5nIHBsYW5lIGlzIHRoZSBjb21wYXJhdGl2ZSB3aXRoIHRoZSByb3V0aW5nIG9yIE1Q TFMgTFNQLg0KDQpGb3IgaW50ZXIgYXJlYSBjYXNlcyBkb26hr3QgeW91IHRoaW5rIGl0oa9zIGlu IFBDRS9Db250cm9sbGVyoa9zIHNjb3BlIHRvIHNldHVwIHBhdGhzIGJhc2VkIG9uIHRoZSBhZHZl cnRpc2VkIE1UVSAoeWVzLCBpZiBNVFUgaXMgYWR2ZXJ0aXNlZCBvbiBBREpzIGFzIHByb3Bvc2Vk IGJlbG93KS4NCltSb2Jpbl0gSW4gZmFjdCwgaW4gdGhlIGNvbW1lbnRzICg4KSBJIGhhdmUgZXhw bGFpbmVkIHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMuIERvIHlvdSB0aGluayB0aGUgc29sdXRpb24g aXMgdG9vIGNvbXBsZXggZm9yIHRoZSBwYXRoIE1UVSBvZiBTUiB3aGljaCBjb3VsZCBoYXZlIGJl IHNvbHZlZCBieSB0aGUgcGF0aCBNVFUgaW5mb3JtYXRpb24gZXhjaGFuZ2UgdGhyb3VnaCBvbmx5 IExEUCBvciBSU1ZQLVRFIHdoaWxlIGZvciB0aGUgU1IgcGF0aCBpdCBoYXMgdG8gaW50cm9kdWNl IElHUC1iYXNlZCBNVFUgYWR2ZXJ0aXNlbWVudCwgdGhlIGVuZC10by1lbmQgcGF0aCBNVFUgY29t cHV0YXRpb24gaW4gdGhlIGluZ3Jlc3Mgbm9kZSwgYW5kIFBDRS1iYXNlZCBlbmQtdG8tZW5kIE1U VSBpbmZvcm1hdGlvbiBjb2xsZWN0aW9uPyAgRXZlbiBzbywgZm9yIFNSLUJFIHBhdGgsIHRoZXJl IGlzIHN0aWxsIGNoYWxsZW5nZXMgZm9yIHRoZSBwYXRoIE1UVS4gTW9yZW92ZXIsIHRoaXMgaXMg anVzdCBmb3IgdGhlIHBhdGggTVRVLiBUYWtpbmcgaW50byBhY2NvdW50IG1vcmUgc2NlbmFyaW9z IHdoaWNoIG5lZWRzIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5naW5nIGFsb25nIHRoZSBub2RlcyBv ZiBMU1Agc3VjaCBhcyBwYXRoIHJlY29yZGluZywgbG9vcCBwcmV2ZW50aW9uLCBlcnJvciBoYW5k bGluZyBhbmQgb3RoZXIgZXhpc3RpbmcgZmVhdHVyZXMgb2YgTERQL1JTVlAtVEUsIHdoYXQgaXMg cG9zc2libGUgY29tcGxleGl0eSBmb3IgU1Igc29sdXRpb25zPw0KDQotLQ0KVW1hIEMuDQoNCkZy b206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXpo ZW5iaW4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAzOjA2IEFNDQpUbzogSGFu bmVzIEdyZWRsZXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRlYXNAaWV0 Zi5vcmcNClN1YmplY3Q6IFttcGxzXSC08Li0OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMgb24gU2Vn bWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0KDQpIaSBIYW5uZXMsDQoN CkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBiYXNlZCBv biB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1AuDQoNClRoZXJlIGFyZSBz dGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVhIGZvciBTUi1URSBwYXRo OiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRlbnNpb25zLCBidXQgYWxz byBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBpdCBoYXMgdG8gaW50cm9k dWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlvbiBhdCB0aGUgaW5ncmVz cyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3NpYmxlIHNv bHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Igd2hpY2ggbWF5IGhhcyBt dWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcgd2l0aCB0aGUgZXhpc3Rp bmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4NCg0KdGhlIG5leHQgY29t bWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEhhbm5lcyBHcmVk bGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNcTqMdTCMjjI1SA0OjAxDQrK 1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgdGVhc0BpZXRmLm9y ZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbc3ByaW5nXSBOZXcgQ29tbWVudHMg b24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25seSBjYW4g c3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUgdXMgYSB3 YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdlIGNvdWxk IGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQgaW1wbGVt ZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3MuDQoNCi9o YW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwgTGl6aGVu YmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcsDQp8DQp8 ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3NlZCBoZXJl IGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0KfA0KfA0K fCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAgICAgMQ0K fCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0tLS0tLS0t LVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8ICAg ICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAgICAgICAg MXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0tLS0tLVMy My0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAgICAgICA0 ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtlIHRoZSB0 b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIgdGhlDQp8 ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBsaWNpdCBw YXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAgaW50ZXJm YWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxhYmVsIHN0 YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRoIGFyZSBk aWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0aXZlIHBh eWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwgYnV0IG1h eSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBwYXRoLiBB cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2YgdGhlDQp8 DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0aGUgcmlz ayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBjYW4gZGVk dWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0KfCAgICB3 aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25lIFNSIHBh dGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAgIFNSLVRF IHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6YXRpb24g YW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lkZXMgYWJv dmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8gdHJhY2sg dGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRocm91Z2gg c2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFkb3B0ZWQg aW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRFIHBhdGgg KGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlzIG5vDQp8 ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlvbi4gSG93 IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sNCnwgICAg dGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2RlcyBhbG9u ZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0KfCAgICBS b2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Uma,

Please refer to my inline comments.

 

Regards,

Robin

 

=B7=A2=BC=FE=C8=CB: Uma Chunduri [uma.chun= duri@ericsson.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C229=C8=D5 12:01
=CA=D5=BC=FE=C8=CB: Lizhenbin; Hannes Gredler
=B3=AD=CB=CD: mpls@ietf.org; spring@ietf.org; teas@ietf.org
=D6=F7=CC=E2: RE: [spring] New Comments on Segment Routing(7): MTU C= hallenges for SR

Hi Robin,

 

If we have MTU issues with in an area, I s= ee trouble in basic IGP functioning (for example it=A1=AFs a serious issue = with IS-IS for basic operation).

[Robin] I agree with you that there exists= the MTU issue for the routing functioning. But the MTU issue can be solved= by the path MTU mechanism provided by LDP/RSVP-TE. My question is whether SR path based on the MPLS forwardin= g plane is the comparative with the routing or MPLS LSP.

 

For inter area cases don=A1=AFt you think = it=A1=AFs in PCE/Controller=A1=AFs scope to setup paths based on the advert= ised MTU (yes, if MTU is advertised on ADJs as proposed below).

[Robin] In fact, in the comments (8) I hav= e explained the possible solutions. Do you think the solution is too comple= x for the path MTU of SR which could have be solved by the path MTU information exchange through only LDP = or RSVP-TE while for the SR path it has to introduce IGP-based MTU advertis= ement, the end-to-end path MTU computation in the ingress node, and PCE-bas= ed end-to-end MTU information collection?  Even so, for SR-BE path, there is still challenges for the path MTU. Moreo= ver, this is just for the path MTU. Taking into account more scenarios whic= h needs the information exchanging along the nodes of LSP such as path reco= rding, loop prevention, error handling and other existing features of LDP/RSVP-TE, what is possible complexity fo= r SR solutions?

 

--

Uma C.

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: mpls@ietf.org; spring@ietf.org; teas@ietf.org
Subject: [mpls] =B4=F0=B8=B4: [spring] New Comments on Segment Routing(7): MTU Challenges= for SR

 

Hi H= annes,

I ha= ve ever thought about the possible solutions based on the flooded MTU infor= mation through IGP.

Ther= e are still two possible issues:

1. I= nter-area for SR-TE path: Maybe we not only introduce the IGP extensions, b= ut also PCEP extensions.

2. F= or SR-BE path, it has to introduce the TE-like end-to-end path calculation = at the ingress node. 

My c= oncern is not just for the possible solutions, but to explore the essence o= f SR which may has muc= h

effect on its deploym= ent comparing with the existing MPLS protocol. It will be explained in

the next comments.

 

 

Regards,

Robin

 

 

 



________________________________________
=B7=A2= =BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5= =BC=FE=C8=CB: Lizhenbin
=B3=AD= =CB=CD: spring@ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank"> mpls@ietf.org; teas@= ietf.org
=D6=F7= =CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for= SR

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org<= br> | https://www.ietf.org/mailman/listinfo/spring

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BACEnkgeml506mbxchi_-- From nobody Wed Jan 28 23:47:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC51A8FD6; Wed, 28 Jan 2015 23:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ytq7iLJdVYab; Wed, 28 Jan 2015 23:47:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43411A0006; Wed, 28 Jan 2015 23:47:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW08063; Thu, 29 Jan 2015 07:47:30 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 07:47:28 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 15:47:17 +0800 From: Lizhenbin To: Robert Raszuk Thread-Topic: [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR Thread-Index: AdA66yE5259u7U/sTZCfhnmR4h4dm///ltGAgAG6xBA= Date: Thu, 29 Jan 2015 07:47:17 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B863@nkgeml506-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: [Teas] =?gb2312?b?tPC4tDogW3NwcmluZ10gTmV3IENvbW1lbnRzIG9uIFNl?= =?gb2312?b?Z21lbnQgUm91dGluZyg4KTogTG9vcCBQcmV2ZW50aW9uIGFuZCBFcnJvciBI?= =?gb2312?b?YW5kbGluZyBmb3IgU1I=?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 07:47:38 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2VyIHJlZmVyIHRvIG15IGlubGluZSBjb21tZW50cy4NCg0KDQoN Cg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQq3orz+yMs6IHJyYXN6dWtAZ21haWwuY29tIFtycmFzenVrQGdtYWlsLmNvbV0g tPqx7SBSb2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldF0NCreiy83KsbzkOiAyMDE1xOox 1MIyOMjVIDIwOjU0DQrK1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnOyBt cGxzQGlldGYub3JnOyB0ZWFzQGlldGYub3JnDQrW98ziOiBSZTogW3NwcmluZ10gTmV3IENvbW1l bnRzIG9uIFNlZ21lbnQgUm91dGluZyg4KTogTG9vcCBQcmV2ZW50aW9uIGFuZCBFcnJvciBIYW5k bGluZyBmb3IgU1INCg0KUm9iaW4sDQoNCk1vc3QgaWYgbm90IG9mIHlvdXIgb2JzZXJ2YXRpb25z IGNpcmNsZSBhcm91bmQgaWRlYSB0byB1c2Ugc2VnbWVudCByb3V0aW5nIGFzIE1QTFMgbGFiZWwg c2lnbmFsbGluZyBtZWNoYW5pc20uIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgdGhhdCBpbnRlcmVz dGluZyBzY2VuYXJpby4gUGVyc29uYWxseSBJIHdvdWxkIG5vdCBkZXBsb3kgaXQgZm9yIHN1Y2gg cHVycG9zZSBvZiBob3AgYnkgaG9wIE1QTFMgc3dpdGNoaW5nLiBXZSBoYXZlIExEUCBmb3IgdGhh dC4NCg0KW1JvYmluXQ0KMS4gSSB3b25kZXIgd2hldGhlciB0aGlzIGlzIHlvdXIgb3duIGlkZWEg b3IgdGhlIHdlbGwtYWNjZXB0ZWQgaWRlYSBvZiBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRp bmcuIEZyb20gdGhlIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWlu dGVyb3AtMDIvZHJhZnQtZnJhbmNvaXMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy10aS1sZmEtMDEs IGl0IHNlZW1zIHRoYXQgdGhlIFNSLUJFIHBhdGggaXMgdGhlIHJlcGxhY2VtZW50IG9mIExEUC4g RnJvbSB0aGUgZHJhZnQtaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nLTAwLCBpdCBzZWVtcyB0aGF0 IHRoZSBTUi1URSBwYXRoIGlzIHRoZSByZXBsYWNlbWVudCBvZiBSU1ZQLVRFLg0KMi4gSSB0aGlu ayB0aGUgcGFja2V0IHN0ZWVyaW5nIGlzIHRydWx5IGFuIGFtYmlndW91cyBjb25jZXB0LiBJIGFn cmVlIHdpdGggeW91ciB1c2VjYXNlcy4gV2UgYWxzbyBhcHByZWNpYXRlZCB0aGUgcG9zc2libGUg Y2hhbmNlcyBwcm9wb3NlZCBieSB0aGUgU1IgYW5kIHByb21vdGUgdGhlIGlkZWEgaW4gbXkgZHJh ZnQgZHJhZnQtbGktc3ByaW5nLW1wbHMtcGF0aC1wcm9ncmFtbWluZy0wMCB0aGF0IE1QTFMgbGFi ZWwgaXMgYmVjb21pbmcgdGhlIGluZGljYXRvciBiZXlvbmQgdGhlIHJlYWNoYWJpbGl0eSBhbmQg Y2FuIGJlIHVzZWQgYXMgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGZsZXhpYmxlIHNlcnZpY2VzIGNv bWJpbmF0aW9uLiBJIHRoaW5rIHRoZXNlIHRvcGljcyBjYW4gZGV2ZWxvcCB0aGUgZXhpc3Rpbmcg SVAvTVBMUyB3b3JsZCBpbnRvIHNvbWUgbmV3IGZpZWxkcy4gQnV0IHRoZSBhbWJpZ3VvdXMgdGhp bmcgaXMgdGhhdCB0aGUgdHJhZGl0aW9uYWwgcm91dGluZyBhbmQgTVBMUyB0cmFmZmljIGVuZ2ll ZXJpbmcgY2FuIGFsc28gYmUgc2VlbiBhcyBzb21lIHR5cGVzIG9mIHRyYWZmaWMgc3RlZXJpbmcu IEkgdGhpbmsgdGhpcyB3aWxsIGJlIHJlcGVhdGVkIHdvcmsgaWYgU1IncyBvYmplY3RpdmUgdG8g c29sdmUgdGhlIGludGVybmFsIGVuZC10by1lbmQgcmVhY2hhYmlsaXR5IGlzc3VlLiBNeSBjb21t ZW50cyBpcyBqdXN0IHRvIGV4cGxhaW4gdGhlIHBvc3NpYmxlIGNoYWxsZW5nZXMgYW5kIGNvbXBs ZXhpdHkgZm9yIElHUC1iYXNlZCBTUiBwYXRoIGNvbXBhcmluZyB3aXRoIHRoZSBleGlzdGluZyBM RFAvUlNWUC1URS4gQW5kIEkgZG8gbm90IHRoaW5rIFNSIGNhbiBzb2x2ZSB0aGUgaXNzdWVzIGJl dHRlciB0aGFuIExEUC9SU1ZQLVRFIHRob3VnaCB0aGVyZSBtYXliZSBzb21lIGFkdmFudGFnZS4g SWYgd2UgY2FuIGJlIGF3YXJlIG9mIHRoaXMsIHdlIHNob3VsZCBzdG9wIHRoZSBjb21wbGV4IHBy b3RvY29sIGV4dGVuc2lvbnMgd29yayBmb3IgU1IgaW4gdGhpcyBmaWVsZC4gT3IgZWxzZSwgaXQg aXMganVzdCB0byBtYWtlIG1lc3MgaW4gdGhlIE1QTFMgd29ybGQgYW5kIHByb2R1Y2UgY29tcGxl eGl0eSBmb3IgdGhlIHNlcnZpY2UgcHJvdmlkZXJzLg0KDQoNClRoaXMgaXMgdGhlIHJlYXNvbiB0 aGF0IHRoZSBTUiBwcm9wb3NlcyB0b28gbWFueSBhbWJpZ3VvdXMgdGhpbmdzIHdoaWNoIEkgd2ls bCBleHBsYWluIGxhdGVyLg0KDQoNCg0KQ29udHJhcnkgSSB3b3VsZCB1c2UgU1IgZm9yIGNvbnRy b2xsZWQgcGFja2V0IHN0ZWVyaW5nIHdoZXJlIHJlc3BvbnNpYmlsaXR5IGlzIHRha2UgdG8gbWFr ZSB0aGUgcmlnaHQgaGVhZGVyIChiZSBpdCBsYWJlbCBvciBleHRlbnNpb24gaGVhZGVycykgdXBv biBvcGVyYXRvciBvciBoaXMgY29udHJvbGxlci4NCg0KVG8gdGhlIHBvaW50IG9mIHRoZSBsb29w IC4uIG5vdGUgdGhhdCB5b3UgbWF5IGhhdmUgdmFsaWQgY2FzZXMgdG8gdHJhdmVyc2UgZ2l2ZW4g YXBwbGlhbmNlIChTRkMgdXNlIGNhc2UpIG1vcmUgdGhlbiBvbmNlcyBoZW5jZSBJIHdvdWxkIGNs YWltIGl0IGlzIG5vdCBhYSBhcmNoaXRlY3R1cmUgc3BlYyBwcm9ibGVtLCBidXQgaWYgc28gZGVw bG95bWVudCBidWcuDQoNCkJlc3QsDQpyLg0KDQoNCg0KT24gV2VkLCBKYW4gMjgsIDIwMTUgYXQg MTI6MzAgUE0sIExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJp bkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIGFsbCBhdXRob3JzIG9mIHNlZ21lbnQgcm91dGlu ZywNCg0KDQoNClRoaXMgaXMgdGhlIGVpZ2h0aCBjb21tZW50cy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFwcGx5IHRvIGJvdGggU1ItVEUgcGF0aCBhbmQgU1ItQkUgcGF0aC4NCg0KDQoNCkZv ciBMRFAgYW5kIFJTVlAtVEUsIHRoZXJlIGlzIHRoZSBsb29wIHByZXZlbnRpb24gbWVjaGFuaXNt IHdoZW4gc2V0dXAgTFNQLiBGb3IgdGhlIFNSLCB0aGUgU1IgcGF0aCBpcyBhbHdheXMNCg0Kc2V0 dXAgYXQgdGhlIGluZ3Jlc3Mgbm9kZS4gSXQgaXMgZGlmZmljdWx0IHRvIGRldGVjdCB0aGUgcG9z c2libGUgbG9vcCBpbiB0aGUgbmV0d29yay4gRm9yIGV4YW1wbGUsIGlmIHRoZQ0KDQptaWNyb2xv b3Agb2Ygcm91dGUgaGFwcGVucywgdGhlIGxvb3AgcHJldmVudGlvbiBtZWNoYW5pc20gd2lsbCBw cmV2ZW50IExEUCB0byBzZXR1cCBMU1AuIEJ1dCBmb3IgdGhlIHNlZ21lbnQNCg0Kcm91dGluZywg b25jZSB0aGUgaW5ncmVzcyBub2RlIGRvd25sb2FkcyB0aGUgZm9yd2FyZGluZyBlbnRyeSBhbmQg dGhlIHRyYWZmaWMgd2lsbCBleHBlcmllbmNlIHRoZSBtaWNyb2xvb3AuDQoNCkhvdyBjYW4gU1Ig dG8gY29wZSB3aXRoIHRoZSBpc3N1ZSBvciBqdXN0IGxlYXZlIGl0IGFzIHRoZSB0cmFkaXRpb25h bCByb3V0aW5nPw0KDQoNCg0KRm9yIExEUCBhbmQgUlNWUC1URSwgdGhlcmUgaXMgdGhlIGVycm9y IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gYmFzZWQgb24gdGhlIExEUCBub3RpZmljYXRpb24gbWVz c2FnZSBvciB0aGUNCg0KUlNWUC1URSBQYXRoRXJyL1Jlc3YgbWVzc2FnZXMuIEJhc2VkIG9uIHRo ZSBlcnJvciBub3RpZmljYXRpb24sIHRoZSBub2RlcyBhbG9uZyB0aGUgTFNQIGNhbiB0YWtlIHBv c3NpYmxlDQoNCmFjdGlvbnMgYWdhaW5zdCB0aGUgcG9zc2libGUgZXJyb3JzLiBCdXQgZm9yIFNS LCB0aGVyZSBpcyBubyBzdWNoIGluZm9ybWF0aW9uIGNvbW11bmljYXRlZCBhbW9uZyB0aGUgbm9k ZXMNCg0KYWxvbmcgdGhlIFNSIFBhdGguIFRoZSByZXN1bHQgd2lsbCBiZSB0aGF0IG9uY2UgdGhl IHBhY2tldCBpcyBmb3J3YXJkZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSwgdGhleSBtYXkNCg0KZXhw ZXJpZW5jZSB0aGUgcG9zc2libGUgZXJyb3JzIHdoaWNoIG1heSBiZSBwcmV2ZW50ZWQgYnkgdGhl IG5lZ290aWF0aW9uIGluIHRoZSBjb250cm9sIHBsYW5lLg0KDQoNCg0KRnJvbSB0aGUgcHJldmlv dXMgY29tbWVudHMsIHdlIGNhbiBzZWUgdGhhdCBpbiB0aGUgdHJhZGl0aW9uYWwgTFNQLCB0aGUg TFNQIHNldHVwIGlzIG5lZ290aWF0ZWQgdGhyb3VnaA0KDQp0aGUgc2lnbmFsbGluZyBiZXR3ZWVu IHRoZSB1cHN0cmVhbSBub2RlIGFuZCB0aGUgZG93bnN0cmVhbSBub2RlLiBEdXJpbmcgdGhlIG5l Z290aWF0aW9uLCBpdCBpcyBub3Qgb25seSB0bw0KDQpzZXQgdXAgdGhlIGZvcndhcmRpbmcgdGhl IGVudHJ5IGZvciB0aGUgcHVycG9zZSBvZiByZWFjaGFibGl0eSwgYnV0IGFsc28gaW5jbHVkZXMg bWFueSBhc3BlY3RzIChJIGNhbGwgdGhlbQ0KDQphcyB0aGUgb3BlcmF0aW9uIGFuZCBtYWludGVu ZW5jZSBvZiB0aGUgTFNQLiBIb3BlIGl0IGlzIGFwcHJvcHJpYXRlLiApIHN1Y2ggYXMgdGhlIGVu ZC10by1lbmQgY29ubmVjdGl2aXR5DQoNCnZlcmlmaWNhdGlvbiwgdGhlIGxvb3AgcHJldmVudGlv biwgcGF0aCBNVFUsIG5lZ290aWF0aW9uLCBwYXRoIHJlY29yZGluZywgZXJyb3Igbm90aWZpY2F0 aW9uIGFuZCBoYW5kbGluZywNCg0KZXRjLiBUaG91Z2ggU1IgYWx3YXlzIHByb3Bvc2VzIGl0cyBh ZHZhbnRhZ2UsIGluIG15IG9waW5pb24sIHRoZXNlIGFkdmFudGFnZXMgYXJlIGZyb20gdGhlIHJl YWNoYWJpbGl0eQ0KDQpwYXJ0IHN1Y2ggYXMgdGhlIGFkdmFudGFnZSB0aGF0IHRoZSBsYWJlbCBz dGF0Y2sgaW4gdGhlIGluZ3Jlc3Mgbm9kZSByZWR1Y2VzIHRoZSBzdGF0ZXMgaW4gdGhlIG5ldHdv cmsuDQoNCkJ1dCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBvcGVyYXRpb25hbCBhbmQgbWFpbnRl bmFuY2UgZm9yIHRoZSB0cmFkaXRpb25hbCBMU1Agc3RpbGwgZXhpc3QuIFRha2luZyBpbnRvDQoN CmFjY291bnQgdGhhdCB0aGUgZmxvb2RpbmcgbW9kZSBvZiB0aGUgSUdQLCBpdCBzdG9wcyB0aGUg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBub2RlcyBhbG9uZyB0aGUgcGF0aCwNCg0KdGhlIHdv cmsgbWF5IGJlY29tZSBtb3JlIGNvbXBsZXguIEFjY29yZGluZyB0byB0aGUgcGFzdCBleHBlcmll bmNlLCB0aGUgcG9zc2libGUgd2F5cyBJIGNvdWxkIHRoaW5rIG91dCBhcmUNCg0KYXMgZm9sbG93 czoNCjEpIERlcGVuZCBvbiB0aGUgdGhpcmQtcGFydHkgbWVjaGFuaXNtcy4gQnV0IHRoZSBwcm9i bGVtIGlzIHRoYXQgdGhlcmUgbWF5IGludm9sdmUgbW9yZSBtZWNoYW5pc21zIGFuZCB0aGVyZQ0K DQptYXkgYmUgbm8gbWVjaGFuaXNtcy4gRm9yIGV4YW1wbGUsIExTUCBQaW5nIGNhbiBiZSBhZG9w dGVkIHRvIGNoZWNrIHRoZSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBvciBsb29wIGZvcg0KDQp0 aGUgU1ItQkUgcGF0aCwgYnV0IGl0IGNhbm5vdCBiZSB1c2VkIGZvciBwYXRoIE1UVSBuZWdvdGlh dGlvbi4gRm9yIHRoZSBlbmQtdG8tZW5kIHBhdGggcmVjb3JkaW5nLCBMU1AgVHJhY2VydA0KDQpt YXkgaGF2ZSB0byBiZSBpbnRyb2R1Y2VkLiBJZiB0aGVzZSByZXF1aXJlbWVudHMgYW5kIG1lY2hh bmlzbXMgYXJlIGNvbnNpZGVyZWQsIGl0IG1lYW5zIFNSIGRvZXMgbm90IHJlZHVjZQ0KDQp0aGUg Y29tcGV4aXR5LiBJbnN0ZWFkIGl0IGp1c3QgdHJhbnNmZXJzIG1vcmUgY29tcGxleGl0eSB0byB0 aGUgb3RoZXIgcG9zc2libGUgc2lnbmFsbGluZ3MuDQoyKSBEZXBlbmQgb24gb25lIG5vZGVzIHRv IGltcGxlbWVudCB0aGUgcG9zc2libGUgZnVuY3Rpb25zLiBGb3IgZXhhbXBsZSwgZm9yIFNSLVRF IHBhdGgsIGl0IGNhbiBkZXBlbmQgb24gdGhlDQoNClBDRSBvciB0aGUgaW5ncmVzcyBub2RlIHRv IGNvbGxlY3QgYWxsIHBhdGggaW5mbyBwcm9wb3NlZCBieSBwYXRoIHJlY29yZGluZyBvciBldmVu IHBhdGggTVRVIG5lZ290aWF0aW9uLiBFdmVuIHNvLA0KDQp0aGVyZSBpcyBzdGlsbCBzb21lIGRy YXdiYWNrcyBmb3Igc29tZSBzY2VuYXJpb3MgaWYgb25seSBkZXBlbmQgb24gdGhlIGluZ3Jlc3Mg bm9kZS4gTW9yZW92ZXIgdGhlc2UgbWV0aG9kcw0KY2Fubm90IGFwcGx5IHRvIFNSLUJFIHBhdGgu SWYgdGhlIHBvc3NpYmxlIHdvcmsgaXMgZG9uZSB0aHJvdWdoIHRoZSBpbmdyZXNzIG5vZGUsIGl0 IHdpbGwgYmVnaW4gdG8gY2hhbmdlIHRoZQ0KDQplc3NlbmNlIG9mIFNSLUJFIGFuZCBiZWNvbWUg dGhlIFNSLVRFLg0KMykgTGVhdmUgYXMgaXQgaXMuIFRoYXQgaXMsIHRoZXNlIGlzc3VlcyBhcmUg bm90IHNvbHZlZCBmb3IgU1IgcGF0aC4gSW4gbXkgb3duIG9waW5pb24sIDIwIHllYXJzIGFnbywg b25seQ0KDQpzb2x2aW5nIHRoZSByZWFjaGFiaWxpdHkgaXNzdWVzIG1heSBiZSBhY2NlcHRlZC4g QnV0IHRvZGF5LCBhcyB0aGUgY29uY2VwdCBvZiBjYXJyaWVyLWdyYWRlIElQIG5ldHdvcmsgaGFz IGJlZW4NCg0Kd2lkZWx5IGFjY2VwdGVkIGFuZCB0aGVzZSBmZWF0dXJlcyBtZW50aW9uZWQgaGFz IGJlZW4gZGVwbG95ZWQgaW4gdGhlIHRyYWRpdGlvbmFsIE1QTFMgbmV0d29yaywgSSBkb24ndCB0 aGluaw0KDQp0aGV5IGNhbiBiZSByZW1vdmVkIGVhc2lseS4NCg0KSW4gb25lIHdvcmQsIHRob3Vn aCBzb21lIGFkdmFudGFnZSBkcml2ZW4gZnJvbSB0aGUgcmVhY2hiaWxpdHkgb2YgU1IgaXMgYXBw YXJlbnQsIHRoZSBjb21wbGV4aXR5IGludHJvY3VkZWQgYnkNCg0KdGhlIHN5bnRoZXNpemVkIHJl cXVpcmVtZW50cyBhcmUgbm90IHJlZHVjZWQuIEFuZCBpdCBtYXkgYmVjb21lIG1vcmUgY29tcGxl eCBmb3IgU1IuDQoNCg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcg bWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg0K --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robert,

Pleaser refer to my inline comments.

 

 

Regards,

Robin

 

 

=B7=A2=BC=FE=C8=CB: rraszuk@gmail.com [rra= szuk@gmail.com] =B4=FA=B1=ED Robert Raszuk [robert@raszuk.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 20:54
=CA=D5=BC=FE=C8=CB: Lizhenbin
=B3=AD=CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7=CC=E2: Re: [spring] New Comments on Segment Routing(8): Loop = Prevention and Error Handling for SR

Robin,

Most if not of your observations circle around idea to use segment routing = as MPLS label signalling mechanism. I do not think this is that interesting= scenario. Personally I would not deploy it for such purpose of hop by hop = MPLS switching. We have LDP for that.
 
[Robin]
1. I wonder whether this is your own idea or the well-accepted idea of all = authors of segment routing. From the draft-filsfils-spring-segment-routing-= ldp-interop-02/draft-francois-spring-segment-routing-ti-lfa-01, it seems th= at the SR-BE path is the replacement of LDP. From the draft-ietf-pce-segment-routing-00, it seems that the SR-T= E path is the replacement of RSVP-TE.
2. I think the packet steering is truly an ambiguous concept. I agree with = your usecases. We also appreciated the possible chances proposed by the SR = and promote the idea in my draft draft-li-spring-mpls-path-programming-00&n= bsp;that MPLS label is becoming the indicator beyond the reachability and can be used as the representation of flex= ible services combination. I think these topics can develop the existi= ng IP/MPLS world into some new fields. But the ambiguous thing is that the = traditional routing and MPLS traffic engieering can also be seen as some types of traffic steering. I think this will= be repeated work if SR's objective to solve the internal end-to-end reacha= bility issue. My comments is just to explain the possible challenges and co= mplexity for IGP-based SR path comparing with the existing LDP/RSVP-TE. And I do not think SR c= an solve the issues better than LDP/RSVP-TE though there maybe some ad= vantage. If we can be aware of this, we should stop the complex p= rotocol extensions work for SR in this field. Or else, it is just to make mess in the MPLS world and produce complexity for the service provide= rs.
 
 
This is the reason that the SR proposes too many ambiguous things which I w= ill explain later.
 
 

Contrary I would use SR for controlled packet steering where responsibility= is take to make the right header (be it label or extension headers) upon o= perator or his controller. 

To the point of the loop .. note that you may have valid cases to traverse = given appliance (SFC use case) more then onces hence I would claim it is no= t aa architecture spec problem, but if so deployment bug.

Best,
r.

 

On Wed, Jan 28, 2015 at 12:30 PM, Lizhenbin <lizhenbin@hua= wei.com> wrote:

Hi all authors of segment routing,

 

This is the eighth comments. The issues proposed = here apply to both SR-TE path and SR-BE path.

 

For LDP and RSVP-TE, there is the loop prevention= mechanism when setup LSP. For the SR, the SR path is always

setup at the ingress node. It is difficult to det= ect the possible loop in the network. For example, if the

microloop of route happens, the loop prevention m= echanism will prevent LDP to setup LSP. But for the segment

routing, once the ingress node downloads the forw= arding entry and the traffic will experience the microloop.

How can SR to cope with the issue or just leave i= t as the traditional routing?

 

For LDP and RSVP-TE, there is the error notificat= ion mechanism based on the LDP notification message or the

RSVP-TE PathErr/Resv messages. Based on the error= notification, the nodes along the LSP can take possible

actions against the possible errors. But for SR, = there is no such information communicated among the nodes

along the SR Path. The result will be that once t= he packet is forwarded by the ingress node, they may

experience the possible errors which may be preve= nted by the negotiation in the control plane.

 

From the previous comments, we can see that in th= e traditional LSP, the LSP setup is negotiated through

the signalling between the upstream node and the = downstream node. During the negotiation, it is not only to

set up the forwarding the entry for the purpose o= f reachablity, but also includes many aspects (I call them

as the operation and maintenence of the LSP. Hope= it is appropriate. ) such as the end-to-end connectivity

verification, the loop prevention, path MTU, nego= tiation, path recording, error notification and handling,

etc. Though SR always proposes its advantage, in = my opinion, these advantages are from the reachability

part such as the advantage that the label statck = in the ingress node reduces the states in the network. 

But the requirements of the operational and maint= enance for the traditional LSP still exist. Taking into

account that the flooding mode of the IGP, it sto= ps the communication between the nodes along the path,

the work may become more complex. According to th= e past experience, the possible ways I could think out are

as follows:
1) Depend on the third-party mechanisms. But the problem is that there may = involve more mechanisms and there

may be no mechanisms. For example, LSP Ping can b= e adopted to check the end-to-end connectivity or loop for

the SR-BE path, but it cannot be used for path MT= U negotiation. For the end-to-end path recording, LSP Tracert

may have to be introduced. If these requirements = and mechanisms are considered, it means SR does not reduce

the compexity. Instead it just transfers mor= e complexity to the other possible signallings.
2) Depend on one nodes to implement the possible functions. For example, fo= r SR-TE path, it can depend on the

PCE or the ingress node to collect all path info = proposed by path recording or even path MTU negotiation. Even so,

there is still some drawbacks for some scenarios = if only depend on the ingress node. Moreover these methods
cannot apply to SR-BE path.If the possible wo= rk is done through the ingress node, it will begin to change the

essence of SR-BE and become the SR-TE.
3) Leave as it is. That is, these issues are not solved for SR path. In my = own opinion, 20 years ago, only

solving the reachability issues may be accepted. = But today, as the concept of carrier-grade IP network has been

widely accepted and= these features mentioned has been deployed in the traditional MPLS network= , I don't think

they can be removed easily.

In one word, though some advantage driven from th= e reachbility of SR is apparent, the complexity introcuded by

the synthesized requirements are not reduced. And= it may become more complex for SR.

 

 

 

 

Regards,

Robin

 

 


_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring


--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB03nkgeml506mbxchi_-- From nobody Thu Jan 29 02:35:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6BC1A1B51; Wed, 28 Jan 2015 20:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 Mt-o83XGF6fM; Wed, 28 Jan 2015 20:01:51 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D905A1A1B71; Wed, 28 Jan 2015 20:01:50 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-b1-54c9518be801 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 68.E1.25146.B8159C45; Wed, 28 Jan 2015 22:15:56 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 23:01:40 -0500 From: Uma Chunduri To: Lizhenbin , Hannes Gredler Thread-Topic: [spring] New Comments on Segment Routing(7): MTU Challenges for SR Thread-Index: AQHQOup31U+M9g3I+kKNm0uu0XRPvpzWeb9A Date: Thu, 29 Jan 2015 04:01:40 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F55CF49@eusaamb105.ericsson.se> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772A9E9@nkgeml506-mbx.china.huawei.com>, <20150127200101.GA21477@hannes-mba.local> <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772B845@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHT7cn8GSIweJvXBb9956wWexu/MNu cWvpSlaL4xd+M1q0/tjB4sDq0XLkLavHkiU/mTyuN11lD2CO4rJJSc3JLEst0rdL4Mq4PHs+ e8GGJYwVi+ZtYW1gfDudsYuRk0NCwERizaYN7BC2mMSFe+vZuhi5OIQEjjBKLG/pZ4ZwljNK LFv2mAWkik1AT+Lj1J9gHSICnhJv7s1iBbGZBbIlvr64wAZiCwsEShz/shiohgOoJkhi+WMF iHIjiaPP1jOB2CwCqhLfFreAlfAK+Ercn2YMseo8o8SH/z2sIHFOgTCJabNCQcoZgW77fmoN E8QmcYlbT+YzQdwsILFkz3lmCFtU4uXjf6wQtpLEpKXnoC7Ll5i/8QuYzSsgKHFy5hOWCYyi s5CMmoWkbBaSMoi4lsS8ht9QNYoSU7ofskPYmhJXJh+CsrUlli18zbyAkX0VI0dpcWpZbrqR 4SZGYPwdk2Bz3MG44JPlIUYBDkYlHt4NhidDhFgTy4orcw8xSnOwKInzll05GCIkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qBcX9YYmSN7pSzK4JymXpnBnP/e31m1aqdzyqlCieeZnvE87DL U3cCH1sQ5457Vd6zw20epK9ZdmB1mk/zEr85mzM+zSksq7wxt4a9iD11lkIcP5/TsvOZs+8d qlB5ddzG7dJNgdXTPljfaJEMiI95p/vF5XHn2wsTZv1h3PFCf1+jUSyT3wbBu0osxRmJhlrM RcWJAOOdvD6gAgAA Archived-At: X-Mailman-Approved-At: Thu, 29 Jan 2015 02:35:14 -0800 Cc: "mpls@ietf.org" , "spring@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [spring] New Comments on Segment Routing(7): MTU Challenges for SR X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 04:01:56 -0000 --_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUm9iaW4sDQoNCklmIHdlIGhhdmUgTVRVIGlzc3VlcyB3aXRoIGluIGFuIGFyZWEsIEkgc2Vl IHRyb3VibGUgaW4gYmFzaWMgSUdQIGZ1bmN0aW9uaW5nIChmb3IgZXhhbXBsZSBpdKGvcyBhIHNl cmlvdXMgaXNzdWUgd2l0aCBJUy1JUyBmb3IgYmFzaWMgb3BlcmF0aW9uKS4NCkZvciBpbnRlciBh cmVhIGNhc2VzIGRvbqGvdCB5b3UgdGhpbmsgaXShr3MgaW4gUENFL0NvbnRyb2xsZXKhr3Mgc2Nv cGUgdG8gc2V0dXAgcGF0aHMgYmFzZWQgb24gdGhlIGFkdmVydGlzZWQgTVRVICh5ZXMsIGlmIE1U VSBpcyBhZHZlcnRpc2VkIG9uIEFESnMgYXMgcHJvcG9zZWQgYmVsb3cpLg0KDQotLQ0KVW1hIEMu DQoNCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaXpoZW5iaW4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAzOjA2IEFNDQpU bzogSGFubmVzIEdyZWRsZXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IHRl YXNAaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSC08Li0OiBbc3ByaW5nXSBOZXcgQ29tbWVudHMg b24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0KDQpIaSBIYW5u ZXMsDQoNCkkgaGF2ZSBldmVyIHRob3VnaHQgYWJvdXQgdGhlIHBvc3NpYmxlIHNvbHV0aW9ucyBi YXNlZCBvbiB0aGUgZmxvb2RlZCBNVFUgaW5mb3JtYXRpb24gdGhyb3VnaCBJR1AuDQoNClRoZXJl IGFyZSBzdGlsbCB0d28gcG9zc2libGUgaXNzdWVzOg0KDQoxLiBJbnRlci1hcmVhIGZvciBTUi1U RSBwYXRoOiBNYXliZSB3ZSBub3Qgb25seSBpbnRyb2R1Y2UgdGhlIElHUCBleHRlbnNpb25zLCBi dXQgYWxzbyBQQ0VQIGV4dGVuc2lvbnMuDQoNCjIuIEZvciBTUi1CRSBwYXRoLCBpdCBoYXMgdG8g aW50cm9kdWNlIHRoZSBURS1saWtlIGVuZC10by1lbmQgcGF0aCBjYWxjdWxhdGlvbiBhdCB0aGUg aW5ncmVzcyBub2RlLg0KDQoNCg0KTXkgY29uY2VybiBpcyBub3QganVzdCBmb3IgdGhlIHBvc3Np YmxlIHNvbHV0aW9ucywgYnV0IHRvIGV4cGxvcmUgdGhlIGVzc2VuY2Ugb2YgU1Igd2hpY2ggbWF5 IGhhcyBtdWNoDQoNCmVmZmVjdCBvbiBpdHMgZGVwbG95bWVudCBjb21wYXJpbmcgd2l0aCB0aGUg ZXhpc3RpbmcgTVBMUyBwcm90b2NvbC4gSXQgd2lsbCBiZSBleHBsYWluZWQgaW4NCg0KdGhlIG5l eHQgY29tbWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQoNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEhhbm5l cyBHcmVkbGVyIFtoYW5uZXNAanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNcTqMdTCMjjI1SA0 OjAxDQrK1bz+yMs6IExpemhlbmJpbg0Ks63LzTogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgdGVhc0Bp ZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4NCtb3zOI6IFJlOiBbc3ByaW5nXSBOZXcgQ29t bWVudHMgb24gU2VnbWVudCBSb3V0aW5nKDcpOiBNVFUgQ2hhbGxlbmdlcyBmb3IgU1INCg0Kb25s eSBjYW4gc3BlYWsgZm9yIElTLUlTIC0NCmFmYWlrIHRoZSBUcmlsbCBleHRlbnNpb25zIGdhdmUg dXMgYSB3YXkgb2Ygc2lnbmFsaW5nIHRoZSBNVFUgb2YgYSBsaW5rIC4uLg0KDQpzbyB3aGF0IHdl IGNvdWxkIGRvIGlzIHRvIGFkdmVydGlzZSB0aGUgTVRVIGZvciBlYWNoIGFkamFjZW5jeSBhbmQg aW1wbGVtZW50DQpwcm9wZXIgZnJhZ21lbnRhdGlvbiBhdCB0aGUgVEUgdHVubmVsIGluZ3Jlc3Mu DQoNCi9oYW5uZXMNCg0KT24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMTE6MjQ6MjNBTSArMDAwMCwg TGl6aGVuYmluIHdyb3RlOg0KfCAgICBIaSBhbGwgYXV0aG9ycyBvZiBzZWdtZW50IHJvdXRpbmcs DQp8DQp8ICAgIFRoaXMgaXMgdGhlIHNldmVudGggY29tbWVucy4gVGhlIGlzc3VlcyBwcm9wb3Nl ZCBoZXJlIGFyZSBmb3IgYm90aCBTUi1URQ0KfCAgICBwYXRoIGFuZCBTUi1CRSBwYXRoLg0KfA0K fA0KfA0KfCAgICAgICAgICAgICAxICAgICAgICAgICAgICAxICAgICAgICAgICAxICAgICAgICAg ICAgMQ0KfCAgICAgIFMxMS0tLS0tLS0tLS0tUzEyLS0tLS0tLS0tLVMxMy0tLS0tLS0tLVMxNC0t LS0tLS0tLVMxNQ0KfCAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgICB8DQp8ICAgICAgMXwgICAgICAgICAgICAxfCAgICAgICAgICAgMXwgICAg ICAgICAgMXwgICAgICAgICAgMXwNCnwgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICAgfA0KfCAgICAgIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0t LS0tLVMyMy0tLS0tLS0tLVMyNC0tLS0tLS0tLVMyNQ0KfCAgICAgICAgICAgICA0ICAgICAgICAg ICAgICA0ICAgICAgICAgICA0ICAgICAgICAgICAgNA0KfA0KfA0KfA0KfCAgICBTdGlsbCB0YWtl IHRoZSB0b3BvbG9neSBpbiB0aGUgY29tbWVudCA2IGFzIHRoZSBleGFtcGxlLiBObyBtYXR0ZXIg dGhlDQp8ICAgIGxvb3NlIGV4cGxpY2l0IHBhdGggb3INCnwNCnwgICAgdGhlIHN0cmljdCBleHBs aWNpdCBwYXRoIGZvciB0aGUgbG9vc2UgaG9wLCBhc3N1bWUgdGhlIE1UVSBvZiB0aGUNCnwgICAg aW50ZXJmYWNlIGlzIHRoZSBzYW1lLA0KfA0KfCAgICBzaW5jZSB0aGUgZGVwdGggb2YgdGhlIGxh YmVsIHN0YWNrcyBmb3IgdGhlIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cA0KfCAgICBwYXRo IGFyZSBkaWZmZXJlbnQuDQp8DQp8ICAgIFRoZXJlIGlzIHRoZSByaXNrIHRoYXQgdGhlIGVmZmV0 aXZlIHBheWxvYWQgbWF5IHRyYW5zbWl0IHRocm91Z2ggdGhlDQp8ICAgIHByaW1hcnkgcGF0aCwg YnV0IG1heSBiZQ0KfA0KfCAgICBmcmFnbWVudGVkIG9yIGRyb3BwZWQgaW4gdGhlIGJhY2t1cCBw YXRoLiBBcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZQ0KfCAgICBsYWJlbCBzdGFja3Mgb2Yg dGhlDQp8DQp8ICAgIHByaW1hcnkgcGF0aCBhbmQgdGhlIGJhY2t1cCBwYXRoIGluY3JlYXNlLCB0 aGUgcmlzayB3aWxsIGluY3JlYXNlLg0KfA0KfA0KfA0KfCAgICBGcm9tIHRoZSBjYXNlLCB3ZSBj YW4gZGVkdWNlIHRoYXQgdGhlIHJpc2sgbWF5IGV4aXN0cyBmb3IgYW55IHNjZW5hcmlvcyBpbg0K fCAgICB3aGljaCB0aGUgc2FtZSB0cmFmZmljDQp8DQp8ICAgICBtYXkgc3dpdGNoIGZyb20gb25l IFNSIHBhdGggdG8gdGhlIG90aGVyIFNSIHBhdGguIFRoZSBTUiBwYXRoIGluY2x1ZGVzDQp8ICAg IFNSLVRFIHBhdGggc3VjaCBhcyBNUExTIFRFDQp8DQp8ICAgIGhvdHN0YW5kYnkvcmVvcHRpbWl6 YXRpb24gYW5kIFNSLUJFIHBhdGggc3VjaCBhcyBUSS1GUlIuDQp8DQp8DQp8DQp8ICAgIEJlc2lk ZXMgYWJvdmUgaXNzdWVzLCBMRFAvUlNWUC1URSBjYW4gc3VwcG9ydCB0aGUgcGF0aCBNVFUgdG8g dHJhY2sgdGhlDQp8ICAgIE1UVSBpbmZvcm1haXRvbiBhbG9uZyB0aGUNCnwNCnwgICAgTFNQIHRo cm91Z2ggc2lnbmFsbGluZy4gVGhlbiB0aGUgcmVhc29uYWJsZSBNVFUgaW5mbyB3aWxsIGJlIGFk b3B0ZWQgaW4NCnwgICAgdGhlIGluZ3Jlc3Mgbm9kZS4gRm9yIGJvdGgNCnwNCnwgICAgIFNSLVRF IHBhdGggKGlmIFBDRSBpcyBub3QgdXNlZCkgYW5kIFNSLUJFIHBhdGgsIHNpbmNlIHRoZXJlIGlz IG5vDQp8ICAgIHNpZ25hbGxpbmcgdG8gYWR2ZXJ0aXNlDQp8DQp8ICAgIHRoZSBpbmZvcm1hdGlv bi4gSG93IHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZT8gT3IgdGhlcmUgbWF5YmUgdGhlIHJpc2sN CnwgICAgdGhhdCB0aGUgcGFja2V0IG1heSBiZQ0KfA0KfCAgICBkcm9wcGVkIGJ5IHRoZSBub2Rl cyBhbG9uZyB0aGUgTFNQLg0KfA0KfA0KfA0KfA0KfA0KfA0KfA0KfCAgICBSZWdhcmRzLA0KfA0K fCAgICBSb2Jpbg0KDQp8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp8IHNwcmluZyBtYWlsaW5nIGxpc3QNCnwgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQp8IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQo= --_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Robin,

 <= /p>

If we have MTU issues wit= h in an area, I see trouble in basic IGP functioning (for example it=A1=AFs= a serious issue with IS-IS for basic operation).

For inter area cases don= =A1=AFt you think it=A1=AFs in PCE/Controller=A1=AFs scope to setup paths b= ased on the advertised MTU (yes, if MTU is advertised on ADJs as proposed below).

 <= /p>

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: mpls@ietf.org; spring@ietf.org; teas@ietf.org
Subject: [mpls] =B4=F0=B8=B4: [spring] New Comments on Segment Routin= g(7): MTU Challenges for SR

 

Hi Hann= es,

I have = ever thought about the possible solutions based on the flooded MTU informat= ion through IGP.

There a= re still two possible issues:

1. Inte= r-area for SR-TE path: Maybe we not only introduce the IGP extensions, but = also PCEP extensions.

2. For = SR-BE path, it has to introduce the TE-like end-to-end path calculation at = the ingress node.

 

My conc= ern is not just for the possible solutions, but to explore the essence of S= R which may has much

effect on its deployment= comparing with the existing MPLS protocol. It will be explained in<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">

the next comments.

 

 

Regards,

Robin

 

 

 <= o:p>



________________________________________
=B7=A2= =BC=FE=C8=CB: Hannes Gredler [hannes@juniper.net]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C228=C8=D5 4:01
=CA=D5= =BC=FE=C8=CB: Lizhenbin
=B3=AD= =CB=CD: spring@ietf.org; mpls@ietf.org; teas@ietf.org
=D6=F7= =CC=E2: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for SR=

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...=

so what we could do is to advertise the MTU for each adjacency and implemen= t
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
|
|    This is the seventh commens. The issues proposed here a= re for both SR-TE
|    path and SR-BE path.
|
|
|
|             1=             &nb= sp; 1           1 &n= bsp;          1
|      S11-----------S12----------S13---------S14-= --------S15
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      1|       = ;     1|        = ;   1|          1|&n= bsp;         1|
|       |      =        |      &= nbsp;     |       &n= bsp;   |         &nb= sp; |
|      S21-----------S22----------S23---------S24-= --------S25
|             4=             &nb= sp; 4           4 &n= bsp;          4
|
|
|
|    Still take the topology in the comment 6 as the example= . No matter the
|    loose explicit path or
|
|    the strict explicit path for the loose hop, assume the = MTU of the
|    interface is the same,
|
|    since the depth of the label stacks for the primary pat= h and the backup
|    path are different.
|
|    There is the risk that the effetive payload may transmi= t through the
|    primary path, but may be
|
|    fragmented or dropped in the backup path. As the differ= ence between the
|    label stacks of the
|
|    primary path and the backup path increase, the risk wil= l increase.
|
|
|
|    From the case, we can deduce that the risk may exists f= or any scenarios in
|    which the same traffic
|
|     may switch from one SR path to the other SR path.= The SR path includes
|    SR-TE path such as MPLS TE
|
|    hotstandby/reoptimization and SR-BE path such as TI-FRR= .
|
|
|
|    Besides above issues, LDP/RSVP-TE can support the path = MTU to track the
|    MTU informaiton along the
|
|    LSP through signalling. Then the reasonable MTU info wi= ll be adopted in
|    the ingress node. For both
|
|     SR-TE path (if PCE is not used) and SR-BE path, s= ince there is no
|    signalling to advertise
|
|    the information. How to implement the feature? Or there= maybe the risk
|    that the packet may be
|
|    dropped by the nodes along the LSP.
|
|
|
|
|
|
|
|    Regards,
|
|    Robin

| _______________________________________________
| spring mailing list
| spring@ietf.org
| https://www.ietf= .org/mailman/listinfo/spring<= /span>

--_000_1B502206DFA0C544B7A60469152008633F55CF49eusaamb105erics_-- From nobody Thu Jan 29 03:00:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B061A01F6; Thu, 29 Jan 2015 03:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Vp-IcE9Cst3N; Thu, 29 Jan 2015 03:00:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147B51A0151; Thu, 29 Jan 2015 03:00:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW30253; Thu, 29 Jan 2015 11:00:02 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 11:00:01 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 18:59:54 +0800 From: Lizhenbin To: "spring@ietf.org" Thread-Topic: New Comments on Segment Routing(9): Challenge of Interoperability of SR with LDP Thread-Index: AdA7rl9TBP+3cFRkTrmNFT7kI3h8ow== Date: Thu, 29 Jan 2015 10:59:54 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6A@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.245] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: [Teas] New Comments on Segment Routing(9): Challenge of Interoperability of SR with LDP X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 11:00:10 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGF1dGhvcnMgb2Ygc2VnbWVudCByb3V0aW5nLA0KDQoNCg0KVGhpcyBpcyB0aGUgbmlu dGggY29tbWVudHMgdG8gZGlzY3VzcyB0aGUgcG9zc2libGUgaXNzdWVzIHByb3Bvc2VkIGJ5IHRo ZSBpbnRlcm9wZXJhYmlsaXR5IG9mIFNSIHdpdGggTERQLg0KDQoNCg0KSW4gZmFjdCwgSSBoYXZl IG5vdCByZWFkIHRoZSBkcmFmdCBkcmFmdC1maWxzZmlscy1zcHJpbmctc2VnbWVudC1yb3V0aW5n LWxkcC1pbnRlcm9wLTAyIHlldC4gQWNjb3JkaW5nIHRvDQoNCnRoZSBwYXN0IGV4cGVyaWVuY2Us IEkgdGhpbmsgdGhlIHBvc3NpbGJlIGNob2ljZSBpcyBubyBvdGhlciB0aGFuIGhpZXJhcmNoeSBv ciBzdGl0Y2hpbmcuDQoNCkkgcHJvcG9zZSB0aGUgZmlyc3QgY2FzZSBhcyB0aGUgZm9sbG93aW5n IHNjZW5hcmlvLA0KDQoNCg0KICAgICAgICAgIFNSICAgICAgICAgIExEUCAgICAgICAgICBMRFAg ICAgICAgICAgU1INCiAgUzExLS0tLS0tLS0tLS1TMTItLS0tLS0tLS0tUzEzLS0tLS0tLS0tUzE0 LS0tLS0tLS0tUzE1DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICB8DQogIFMyMS0tLS0tLS0tLS0tUzIyLS0tLS0tLS0tLVMyMy0tLS0tLS0tLVMy NC0tLS0tLS0tLVMyNQ0KDQpBc3N1bWUgYWxsIG90aGVyIG5vZGVzIHN1cHBvcnQgU1IgYW5kIG9u bHkgUzEyL1MxMy9TMTQgc3VwcG9ydCBMRFAuIElmIHRoZSBMU1Agc3RpdGNoaW5nIGlzIGFkb3B0 ZWQsIHRoZXJlIHdpbGwNCg0KYmUgZm9sbG93aW5nIHByb2Nlc3M6DQotLSBJbiBTMTIsIHRoZSBl Z3Jlc3MgU1ItQkUgcGF0aCB3aWxsIHN0aXRjaCB0aGUgaW5ncmVzcyBMRFAgTFNQLCBJZiB0aGUg bGluayBiZXR3ZWVuIHRoZSBTMTIgYW5kIFMxMyBmYWlscw0KDQpmaXJzdGx5LCB0aGVuIHJlc3Rv cmVkLCB0aGUgSUdQLUxEUCBzeW5jIGlzIGFsc28gbmVjZXNzYXJ5Lg0KLS0gSW4gUzE0LCB0aGUg ZWdyZXNzIExEUCBMU1Agd2lsbCBzdGl0Y2ggdGhlIGluZ3Jlc3MgU1ItQkUgcGF0aC4NCg0KDQoN Ck1vcmV2b2VyLCBpZiB0aGUgc2NlbmFyaW8gaXMgY2hhbmdlcyB0byB0aGUgb3Bwb3NpdGUgd2F5 LCB0aGF0IGlzIGFsbCBvdGhlciBub2RlcyBzdXBwb3J0IExEUCBhbmQgb25seSBTMTIvUzEzL1Mx NA0KDQpzdXBwb3J0IFNSLCBpdCBoYXMgdG8gaW50cm9kdWNlIHRoZSBwcm94eSBlZ3Jlc3MgZm9y IFNSLUJFIHBhdGggd2hpY2ggaGFzIGV4cGxhaW5lZCBpbiB0aGUgcHJldmlvdXMgY29tbWVudHMg dGhhdA0KDQppdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIFNSLg0K DQoNCg0KRnJvbSB0aGUgY2FzZSwgY291bGQgSSBzYXkgdGhhdCB0aGUgU1ItTERQIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgaXMgbW9yZSBkaWZmaWN1bHQgdGhhdCB0aGUgSUdQLUxEUCBzeW5jDQoN CndoaWNoIGNvdWxkIGJlIHJlbW92ZWQgYnkgU1IgYXMgY2xhaW1lZD8NCg0KDQoNCg0KDQpJIHBy b3Bvc2UgdGhlIHNlY29uZCBjYXNlIGFzIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8sDQoNCg0KDQog ICAgICAgICAgTERQICAgICAgICAgIExEUA0KICBTMTEtLS0tLS0tLS0tLVMxMi0tLS0tLS0tLS1T MTMNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiBTUnwgICAgICAgICAgICAgICAg ICAgICAgICAgIHxTUg0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICBTMjEtLS0t LS0tLS0tLVMyMi0tLS0tLS0tLS1TMjMNCiAgICAgICAgU1IgICAgICAgICAgICAgU1INCg0KDQoN CkFzc3VtZSBTMTEvUzEyL1MxMyBzdXBwb3J0IExEUCBhbmQgUzExL1MyMS9TMjIvUzIzL1MxMyBz dXBwb3J0IFNSLiBJZiB0aGUgcHJpbWFyeSBwYXRoIHRvIFMxMyBpcyBTMTEtPlMxMi0+UzEzDQoN CmlzIGJhc2VkIG9uIExEUCBMU1AuIEluIG9yZGVyIHRvIGFjaGlldmUgdGhlIDEwMCUgbmV0d29y ayBjb3ZlcmFnZSwgTERQIHJlbW90ZSBwZWVyIGNhbiBiZSBzZXQgdXAgYmV0d2VlbiBTMTENCg0K YW5kIFMxMyB0byBhZHZlcnRpc2UgbGFiZWwgbWFwcGluZyBkaXJlY3RseSBmcm9tIHRoZSBTMTMg dG8gUzExLiBUaGUgdGhlIGJhY2t1cCBwYXRoIGNhbiBiZTogdGhlIGJhY2t1cCBMRFANCg0KbGFi ZWwgZ29lcyB0aHJvdWdoIHRoZSBTUiBwYXRoIFMxMS0+UzIxLT5TMjItPlMyMy0+UzEzLiBUaGlz IG1lYW5zIHRoYXQgdGhlIFJlbW90ZSBMRkEgbXVzdCBjby1leGlzdCB3aXRoIFRJLUxGQS4NCg0K Q291bGQgSSBzYXkgdGhhdCB0aGUgY29tYmluZWQgRlJSIHNvbHV0aW9ucyBpcyBtb3JlIGNvbXBs ZXggdGhhbiBvbmUgb2YgdGhlc2UgRlJSIHNvbHV0aW9ucz8NCg0KDQoNCkZyb20gdGhlIHBlcnZp b3VzIGNvbW1lbnRzLCB3ZSBjYW4gc2VlIHRoYXQgc29tZSBvZiB0aGUgZXhpc3RpbmcgTERQIHNj ZW5hcmlvcyBjYW5ub3QgYmUgc3VwcG9ydGVkIGJ5IFNSLUJFIHBhdGguDQoNClRoaXMgbWVhbnMg aWYgU1IgaXMgYWRvcHRlZCwgaXQgaGFzIHRvIGNvLWV4aXN0IHdpdGggTERQIGluIHRoZXNlIHNj ZW5hcmlvcy4gRm9yIHRoZSBsZWdhY3kgbmV0d29yayB1c2luZyBMRFAsDQoNCmlmIFNSIGlzIGFk b3B0ZWQgdG8gcmVwbGFjZSB0aGUgTERQLCBpdCBpcyBhbHNvIGluZXZpdGFibGUgdGhhdCB0aGUg U1IgaGFzIHRvIGNvLWV4aXN0IHdpdGggTERQLg0KDQoNCg0KSWYgdGhlc2Ugc2NlbmFyaW9zIGhh cHBlbnMsIHRoZXJlIHdpbGwgYmUgYSBtZXNzIG9mIHNvbHV0aW9ucyBpbiB0aGUgbmV0d29yay4g SW4gZmFjdCwgdGhpcyBpcyBub3QgYSBuZXcgb25lLg0KDQpBbG1vc3QgdGVuIHllYXJzIGFnbywg d2hlbiB3ZSBpbXBsZW1lbnRlZCB0aGUgTERQLCB3ZSBhc3N1bWVkIHRoYXQgdGhlcmUgY2FuIGJl IG9uZSBuZXR3b3JrIGluIHdoaWNoIHNvbWUgbm9kZXMNCg0KcnVuIExEUCBEb0QsIG90aGVycyBy dW4gTERQIERVLCBzb21lIG5vZGVzIHJ1biBMRFAgT3JkZXJlZCwgb3RoZXJzIHJ1biBMRFAgSW5k ZXBlbmRlbnQsIHNvbWUgbm9kZXMgcnVuIExEUCBsaWJlcmFsLA0KDQpvdGhlcnMgcnVuIExEUCBj b25zZXJ2YXRpdmUuIEZpbmFsbHkgd2UgZm91bmQgdGhlIGlzc3VlcyBjb3VsZCBub3QgY29udmVy Z2UgYXQgYWxsLiBBdCBsYXN0IHdlIGhhZCB0byBnaXZlIHVwDQoNCmFuZCBwcm92aWRlZCB0aGUg c3BlY2lmaWNhdGlvbiBmb3IgYW55IG5ldHdvcmsgdGhlcmUgaXMgb25seSBvbmUgbGFiZWwgYWR2 ZXJ0aXNlbWVudCBtb2RlLCBvbmx5IG9uZSBsYWJlbA0KDQpkaXN0cmlidXRpb24gbW9kZSwgb25s eSBvbmUgbGFiZWwgcmV0ZW50aW9uIG1vZGUuIFVudGlsIHRvZGF5IERVICsgT3JkZXJlZCArIExp YmVyYWwgYmVjb21lcyBhbG1vc3QgdGhlIG1vc3QNCg0KcG9wdWxhciBjaG9pY2UuDQoNCg0KDQpC dXQgZm9yIFNSLCBpdCB3b3JrcyBpbiB0aGUgdG90YWxseSBkaWZmZXJlbnQgd2F5IGZyb20gdGhl IExEUCBpbiBtYW55IGFzcGVjdHMuIElmIFNSIGFuZCBMRFAgY28tZXhpc3QgaW4gb25lDQoNCm5l dHdvcmsgYW5kIHRoZSBiZWhhdmlvcnMgY291bGQgbm90IGJlIHVuaWZ5ZWQgdGhyb3VnaCB0aGUg dW5pZnlpbmcgY29uZmlndXJhdGlvbiwgdGhlIG1lc3Mgb2YgdGhlIHNvbHV0aW9ucw0KDQppcyBp bmV2aXRhYmxlLiBUYWtpbmcgaW50byBhY2NvdW50IFNSJ3MgaW50ZXJ3b3JraW5nIHdpdGggTERQ J3MgdHdvIExTUCBhZHZlcnRpc2VtZW50IG1vZGUsIHR3byBMU1AgZGlzdHJpYnV0aW9uDQoNCm1v ZGUsIHR3byBsYWJlbCByZXRlbnNpb24gbW9kZSwgdHdvIHR5cGVzIG9mIExEUCBwZWVyIGFzIHdl bGwgYXMgbmV3IElHUC1MRFAgc3RpY2hpbmcvaGllcmFyY2h5L3N5bmMgYW5kIHRoZQ0KDQppbnR3 b3JraW5nIExGQS9SLUxGQSBGUlIgZm9yIExEUCB3aXRoIHRoZSBUSS1MRkEgZm9yIFNSLCBJIGRv bid0IHRoaW5rIHRoaXMgaXMgYW4gZWFzeSB3b3JrIHRvIGNsYXJpZnkgYWxsDQoNCnBvc3NpYmxl IGRldGFpbHMgaW4gb25lIGRyYWZ0IGFuZCBtdWNoIG9mIHRoZSBkZXRhaWxzIG1heWJlIGltcGxl bWVudGF0aW9uIHNwZWNpZmljIGFuZCBwb3RlbnRpYWwgcmlzayBmb3IgdGhlDQppbnRlcm9wZXJh YmlsaXR5LiBNb3Jlb3ZlciwgYmFzZWQgb24gdGhlIGFuYWx5c2lzIGluIHRoZSBwcmV2aW91cyBj b21tZW50cywgdGhlcmUgaXMgc29tZSByZXF1aXJlbWVudHMgb2YgTERQDQoNCndoaWNoIGNhbm5v dCBiZSBzdXBwb3J0ZWQgYnkgU1ItQkUgcGF0aCB5ZXQgbm93LiBJZiB0aGVzZSBpc3N1ZXMgYXJl IG5vdCBzb2x2ZWQsIHRoZSBpbnRyb2R1Y2luZyBvZiBTUiBpbiB0aGUNCg0KTERQIG5ldHdvcmsg d2lsbCBhZmZlY3QgdGhlIG5vcm1hbCBwcm9jZXNzIG9mIExEUC4NCg0KDQoNCkFjY29yZGluZyB0 byB0aGUgYWJvdmUgYW5hbHlpc2lzLCBteSByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIG5ldHdvcmsg dHJhbnNpdGlvbiBpcyB0aGF0IGlmIHRoZXJlIGlzIHRoZSBzY2VuYXJpbw0KDQppbiB3aGljaCBT Ui1CRSBwYXRoIGlzIHRydWx5IGFwcGxpY2FibGUsIGl0IGlzIGJldHRlciB0byByZXBsYWNlIHRo ZSBleGlzdGluZyBMRFAgYWxsIGF0IG9uY2UgdG8gYXZvaWQgdGhlIHBvc3NpYmxlDQoNCmludGVy b3BlcmFiaWxpdHkgaXNzdWUuDQoNCg0KDQpSZWdhcmRpbmcgdGhlIGludGVyb3BlcmFiaWxpdHkg b2YgU1ItVEUgcGF0aCB3aXRoIFJTVlAtVEUsIHRoZSBnZW5lcmFsIHByb2JsZW0gaXMgdGhhdCBi b3RoIFNSLVRFIHBhdGggYW5kIFJTVlAtVEUNCg0KY2Fubm90IHN1cHBvcnQgcHJveHkgZWdyZXNz IG5vdyBhbmQgdGhlIHN0aXRjaGluZyB3b3VsZCBub3Qgd29yayBhdCBhbGwuIFRoZSBvbmx5IHdh eSBpcyBqdXN0IHRvIHJlcGxhY2UgdGhlIHdob2xlDQoNClJTVlAtVEUgTFNQIHdpdGggdGhlIFNS LVRFIHBhdGggaWYgdGhlIFNSLVRFIHBhdGggaXMgdHJ1bHkgYXBwbGljYWJsZS4NCg0KDQoNCg0K DQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg0KDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all authors of segment routing,

 

This is the ninth comments to discuss the possibl= e issues proposed by the interoperability of SR with LDP.

 

In fact, I have not read the draft draft-filsfils= -spring-segment-routing-ldp-interop-02 yet. According to

the past experience, I think the possilbe choice = is no other than hierarchy or stitching.


I propose the first case as the following scenario,<= /font>

 

        &= nbsp; SR          LDP &nb= sp;        LDP    &n= bsp;     SR
  S11-----------S12----------S13---------S14---------S15
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
   |          &= nbsp;  |          &n= bsp; |           | &= nbsp;         |
  S21-----------S22----------S23---------S24---------S25

Assume all other nodes support SR and o= nly S12/S13/S14 support LDP. If the LSP stitching is adopted, there will

be following process:
-- In S12, the egress SR-BE path will stitch the ingress LDP LSP, If the li= nk between the S12 and S13 fails

firstly, then restored, the IGP-LDP sync is = also necessary.
-- In S14, the egress LDP LSP will stitch the ingress SR-BE path.

 

Morevoer, if the scenario is changes to the oppos= ite way, that is all other nodes support LDP and only S12/S13/= S14

support SR, it has to introduce the proxy egress = for SR-BE path which has explained in the previous comments that <= /font>

it will be difficult to be supported by the SR.

 

From the case, could I say that the SR-LDP intero= perability issue is more difficult that the IGP-LDP sync

which could be removed by SR as claimed? <= /p>

 

 


I propose the second case as the following scenario,=

 

        &= nbsp; LDP          LDP &n= bsp;   
  S11-----------S12----------S13
   |          &= nbsp;           &nbs= p;   |
 SR|           =             &nb= sp;  |SR
   |          &= nbsp;           &nbs= p;   |
  S21-----------S22----------S23
        SR     =         SR

 

Assume S11/S12/S13 support LDP and S11/S21/S22/S2= 3/S13 support SR. If the primary path to S13 is S11->S12->S13

is based on LDP LSP. In order to achieve the 100%= network coverage, LDP remote peer can be set up between S11

and S13 to advertise label mapping directly from = the S13 to S11. The the backup path can be: the backup LDP

label goes through the SR path S11->S21->S2= 2->S23->S13. This means that the Remote LFA must co-exist with TI-LFA= .

Could I say that the combined FRR solutions is mo= re complex than one of these FRR solutions?

 

From the pervious comments, we can see that some = of the existing LDP scenarios cannot be supported by SR-BE path.

This means if SR is adopted, it has to co-exist w= ith LDP in these scenarios. For the legacy network using LDP,

if SR is adopted to replace the LDP, it is also i= nevitable that the SR has to co-exist with LDP.

 

If these scenarios happens, there will be a mess = of solutions in the network. In fact, this is not a new one.

Almost ten years ago, when we implemented the LDP= , we assumed that there can be one network in which some nodes

run LDP DoD, others run LDP DU, some nodes run LD= P Ordered, others run LDP Independent, some nodes run LDP liberal,

others run LDP conservative. Finally we found the= issues could not converge at all. At last we had to give up

and provided the specification for any network th= ere is only one label advertisement mode, only one label

distribution mode, only one label retention mode.= Until today DU + Ordered + Liberal becomes almost the most

popular choice.

 

But for SR, it works in the totally dif= ferent way from the LDP in many aspects. If SR and LDP co-exist in one

network and the behaviors could not be unifyed th= rough the unifying configuration, the mess of the solutions

is inevitable. Taking into account SR's interwork= ing with LDP's two LSP advertisement mode, two LSP distribution

mode, two label retension mode, two types of LDP = peer as well as new IGP-LDP stiching/hierarchy/sync and the

intworking LFA/R-LFA FRR for LDP with the TI-LFA = for SR, I don't think this is an easy work to clarify all

possible details in one draft and much of the det= ails maybe implementation specific and potential risk for the
interoperability. Moreover, based on the analysis in the previous comments,= there is some requirements of LDP

which cannot be supported by SR-BE path yet now. = If these issues are not solved, the introducing of SR in the

LDP network will affect the normal process of LDP= .

 

According to the above analyisis, my recommendati= on for the network transition is that if there is the scenario

in which SR-BE path is truly applicable, it is be= tter to replace the existing LDP all at once to avoid the possible

interoperability issue.

 

Regarding the interoperability of SR-TE path with= RSVP-TE, the general problem is that both SR-TE path and RSVP-TE

cannot support proxy egress now and the stitching= would not work at all. The only way is just to replace the whole

RSVP-TE LSP with the SR-TE path if the SR-TE path= is truly applicable.

 

 

 

Regards,

Robin

 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D4772BB6Ankgeml506mbxchi_-- From nobody Fri Jan 30 16:57:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30631A87EB; Fri, 30 Jan 2015 16:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Osrftni30f1B; Fri, 30 Jan 2015 16:57:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1743C1A012D; Fri, 30 Jan 2015 16:57:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131005744.26128.25703.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 16:57:44 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-gmpls-resource-sharing-proc-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 00:57:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing Authors : Xian Zhang Haomian Zheng Rakesh Gandhi Zafar Ali Gabriele Maria Galimberti Pawel Brzozowski Filename : draft-ietf-teas-gmpls-resource-sharing-proc-01.txt Pages : 13 Date : 2015-01-30 Abstract: In transport networks, there are requirements where Generalized Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs. This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document clarifies the RSVP-TE signaling procedure to support resource sharing-based setup and teardown of LSPs as well as LSP reversion. No new extensions are defined by this document, and it is strictly informative in nature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-resource-sharing-proc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-gmpls-resource-sharing-proc-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-resource-sharing-proc-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 30 17:36:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4221A87F2 for ; Fri, 30 Jan 2015 17:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mhzL1WCP2NfW for ; Fri, 30 Jan 2015 17:36:38 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16621A8829 for ; Fri, 30 Jan 2015 17:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2624; q=dns/txt; s=iport; t=1422668190; x=1423877790; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cQ0E1QGHyDKzGUOxqzAPbFpvN4MDDL+7Z0qEJgf5LCI=; b=UxliMXNjmVcPIOfygHTs0HETBGUfEDg7HXgIogk7FYQD+B9PtYmbNpzT Wfvd3NPw+SZwT1b8gZnh8bN2EstXYuopqwPOCPnVUAmnGSpqk67viJwvR R36CioyjVheEAI5ZjVQRWLVDnKtMB+tFPySaLc3gd25zv03Szg5ukrAmE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQBTMcxU/5RdJa1agwZSVAUExGAMhW8CgRVDAQEBAQF9hA0BAQQBAQE3NB0BCBIkNwsXDgIEEwmIIwgFsEulHAEBAQEGAQEBAQEdj0U6hCkFjR6BY4NOhVeBFzaCTYsCgz0ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,495,1418083200"; d="scan'208";a="119176442" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 31 Jan 2015 01:36:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0V1aTrI003470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 31 Jan 2015 01:36:29 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 19:36:29 -0600 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-gmpls-resource-sharing-proc-01.txt Thread-Index: AQHQPPZVv0/xDUMGg0SyR5+G+5jy7A== Date: Sat, 31 Jan 2015 01:36:29 +0000 Message-ID: In-Reply-To: <20150131005744.26128.25703.idtracker@ietfa.amsl.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.222.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <69AFC853BD335C49BE38D7BFA441EE31@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-gmpls-resource-sharing-proc-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:36:40 -0000 Hi WG, The draft is edited to address comments received in Hawaii. Welcome your review comments. =20 thanks, Rakesh and authors On 2015-01-30 7:57 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Traffic Engineering Architecture and >Signaling Working Group of the IETF. > > Title : RSVP-TE Signaling Procedure for End-to-End >GMPLS Restoration and Resource Sharing > Authors : Xian Zhang > Haomian Zheng > Rakesh Gandhi > Zafar Ali > Gabriele Maria Galimberti > Pawel Brzozowski > Filename : draft-ietf-teas-gmpls-resource-sharing-proc-01.txt > Pages : 13 > Date : 2015-01-30 > >Abstract: > In transport networks, there are requirements where Generalized > Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme > needs to employ restoration Label Switched Path (LSP) while keeping > resources for the working and/or protecting LSPs reserved in the > network after the failure occurs. > > This document reviews how the LSP association is to be provided using > Resource Reservation Protocol - Traffic Engineering (RSVP-TE) > signaling in the context of GMPLS end-to-end recovery scheme when > using restoration LSP where failed LSP is not torn down. In > addition, this document clarifies the RSVP-TE signaling procedure to > support resource sharing-based setup and teardown of LSPs as well as > LSP reversion. No new extensions are defined by this document, and > it is strictly informative in nature. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-resource-sharing-pr >oc/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-teas-gmpls-resource-sharing-proc-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-gmpls-resource-sharing-= pr >oc-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas